Techniques for obstacle detection and avoidance

ABSTRACT

Systems and methods are provided herein for obstacle detection and avoidance. An obstacle (e.g., a fallen object, an area of congestion, etc.) may be detected utilizing sensor data and/or navigational information provided by various components of a workspace (e.g., mobile drive units, standalone sensors, etc.). Obstacle information corresponding to the obstacle may be utilized to identify tasks within the workspace that may be affected by the obstacle. Paths for these affected tasks may be altered and any subsequent path generated by the system may be generated based at least in part on the obstacle, so long as the obstacle exists. Utilizing the techniques provided herein, the workflows/tasks/paths of the components of the system may be managed so as to avoid interactions between the components of the system and any known obstacle.

BACKGROUND

Modern inventory systems, such as those in storage and/or sortationfacilities (e.g., a warehouse, sortation warehouse) face significantchallenges with respect to managing items in inventory. Items may bemoved from one location to another within a facility. These functionscan be performed by a myriad of robotic devices (e.g., mobile driveunits (MDUs)). As these devices travel about the facility, unexpectedobstacles may be encountered such as fallen objects, misplaced storagecontainers, traffic congestion, or the like.

Conventional systems may lack effective methods for obstacle detectionand avoidance. Embodiments of the invention address these and otherproblems.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments in accordance with the present disclosure will bedescribed with reference to the drawings, in which:

FIG. 1 is a schematic diagram illustrating an example environmentsuitable for implementing aspects of an obstacle management engine, inaccordance with at least one embodiment;

FIG. 2 is a schematic diagram illustrating techniques for performing aremedial action in response to obstacle detection, in accordance with atleast one embodiment;

FIG. 3 is a schematic diagram illustrating additional techniques forperforming a remedial action in response to obstacle detection, inaccordance with at least one embodiment;

FIG. 4 is a block diagram illustrating an example method for performingat least one remedial action based at least in part on obstacledetection within a workspace, in accordance with at least oneembodiment;

FIG. 5 is an example system architecture for implementing aspects of aninventory system, in accordance with at least one embodiment;

FIG. 6 illustrates in greater detail the components of an examplemanagement module, including an obstacle management engine that may beutilized in at least one embodiment;

FIG. 7 is a flowchart illustrating an example method for performing oneor more remedial actions in response to obstacle detection within aworkspace, in accordance with at least one embodiment;

FIG. 8 is a flowchart illustrating another example method performing aremedial action in response to obstacle within a workspace, inaccordance with at least one embodiment;

and

FIG. 9 is a flowchart illustrating an example method 900 for alteringtask execution in response to obstacle detection, in accordance with atleast one embodiment.

DETAILED DESCRIPTION

Techniques described herein are directed to systems and methods fordetecting and/or avoiding obstacles within a workspace. Althoughexamples throughout may utilize warehouses, sortation facilities,storage facilities, and/or warehouse machinery for illustrativepurposes, it should be appreciated that any example herein may beequally applied to other suitable contexts. As used herein, an“obstacle,” may include fallen objects, misplaced objects, restrictedspaces, storage containers, congestion associated with a plurality ofMDUs, liquid on the ground, or the like. A “restricted space” maycorrespond to a location and/or area within the workspace that is to beavoided by the MDUs of the workspace. As used herein, “congestion” isintended to refer a situation within the workspace in which over athreshold number of components (e.g., MDUs, user computing devices,robotic arms, etc.) are located within a predetermined area size.Throughout the description below, examples that utilize one or more MDUsmay equally apply to situations that include any suitable combination ofone or more MDUs and/or one or more user devices (e.g., an electronicdevice worn, carried, operated by, or otherwise generally associatedwith an individual within the storage facility). Any functionalitydescribed with respect to the workspace management module and/orobstacle management engine described herein may be provided to and/or byan MDU and/or a user computing device. Thus, it is envisioned that theworkspace management module and/or the obstacle management enginediscussed herein may provide obstacle detection and/or avoidanceinvolving any suitable combination of one or more MDUs and/or one ormore user computing devices and/or one or more robotic arms within aworkspace. Accordingly, any of the examples herein that utilize an MDUmay be similarly applied to use cases involving a user computing deviceand/or a robotic device.

In at least one embodiment, a management module may be responsible fordetermining tasks and assigning individual tasks to individual MDUswithin a storage and/or sortation facility operated by, or on behalf ofan electronic marketplace provider (e.g., an online retailer of physicalitems). For example, the workspace management module may determine thatan item (e.g., a single item, a pallet, a cart, or any suitablecontainer that stores one or more items) is to be moved from a firstlocation (e.g., a receiving workstation) to a second location (e.g., adesignated storage location within a storage facility, a destinationlocation within a sortation facility, etc.). The workspace managementmodule may determine a storage and/or destination location for the itembased on any suitable techniques.

In at least one embodiment, the workspace management module maydetermine a particular MDU of a set of MDUs operating in the facility.The particular MDU can be determined, for example, based at least inpart on the first location, the second location, a location of theparticular MDU, or any suitable combination of the above. For example,an MDU that is closest to the first location may be selected. Theworkspace management module (or individual components/agents of theworkspace management module associated with individual MDUs) maygenerate a set of commands that instruct the MDU to perform a task(e.g., retrieve the item from the first location and deliver it to thesecond location). In some embodiments, the workspace management module(or a component of the workspace management module) may generate andincrementally provide the set of commands to the tasked MDU. Theworkspace management module may wait to provide another command until itreceives an indication from the MDU that it has successfully completedthe previous command.

In at least one embodiment, the MDUs may be configured to providenavigational information (e.g., current location, current speed, currentstate, etc.) that indicates respective locations of the MDUs. In someembodiments, the navigational information may correspond to any suitablenumber of time periods (e.g., 2 second time periods, 500 millisecondtime periods, etc.). In some examples, each MDU in the workspace maytransmit navigational information periodically, at any suitablefrequency, upon completion of an assigned task, or the like. Each MDUmay further include one or more sensors (e.g., an infrared sensor, adigital camera, a video camera, an RFID scanner and/or an RFID tab,etc.). These sensors may be configured to provide sensor data at anysuitable time (e.g., periodically, at any suitable frequency, upondetecting an object, etc.).

An obstacle management engine (e.g., operating as part of the workspacemanagement module 102 or as a separate service/process/standalonemodule) may be configured to detect one or more obstacles within theworkspace based at least in part on the navigational information and/orthe sensor data provided by the MDUs of the workspace. The obstaclemanagement engine may generate obstacle information for each obstacledetected within the workspace. As used herein, “obstacle information” isintended to refer to any suitable data that describes one or moreattributes (e.g., type, size, shape, duration of existence, etc.) of anobstacle. In some embodiments, obstacle information may include anysuitable combination of navigational information and/or sensor dataprovided by one or more MDUs related to an obstacle. The functionalityof the obstacle management engine may be executed at any suitable time.By way of example, the obstacle management engine may be configured toexecute various obstacle detection and/or avoidance operationsperiodically, at a set frequency (e.g., every 500 milliseconds),according to a predetermined schedule, or the like.

As a non-limiting example, an MDU in the course of performing itsassigned task, may encounter an obstacle (e.g., a fallen package on thefloor of the storage facility, a closed door, a puddle of liquid, anarea of congestion, etc.). In at least one example, the MDU may providevarious information (e.g., sensor data related to the obstacle,navigational information such as a location of the MDU, a location ofthe obstacle, an obstacle type, or the like). In some cases, providingthis information may constitute a request by the MDU for furtherinstructions, while in other cases, the MDU may transmit a separaterequest for further instructions to the workspace management module. Inat least one example, other obstacle sensing devices (e.g., cameras,infra-red sensors, etc. affixed to stationary and/or moveable/movingobjects) may generate sensor data which may be received by the workspacemanagement module and/or the obstacle management module. The obstaclemanagement module may access any received navigational data and/orsensor data to identify one or more obstacles within the workspace.

As a non-limiting example, the obstacle management engine may beconfigured to obtain and/or generate obstacle information correspondingto an area of congestion within the workspace. Obstacle informationcorresponding to an area of congestion may include any suitable datathat describes the congestion within the congested area. In someembodiments, the obstacle management engine may be configured to detectcongestion within the workspace utilizing historic, current, and/orplanned locations associated with the MDUs. In some embodiments, theobstacle management engine may be configured to detect congestionoccurring currently, congestion observed in the past, and/or congestionthat is likely to occur in the future. In some embodiments, the obstaclemanagement engine may generate and/or obtain a grid of overlappingvolumes, each volume corresponding to a sub-area of the workspace. Theobstacle management engine may utilize navigational information providedby the MDUs and/or planned path data associated with the MDUs togenerate a density value for each volume. A density value may indicate anumber of components (e.g., MDUs) within a given volume during aparticular time period (e.g., a historical time period, a future timeperiod, etc.). For each of the highly dense volumes (e.g., volumeshaving a number of MDUs over a threshold value), the obstacle managementengine may generate a density volume for each time period. In someembodiments, the obstacle management engine may utilize a predeterminedprotocol to classify particular volumes as being congested based atleast in part on density values corresponding to historical time periodsand/or density values corresponding to future time period(s). Furtherexamples of congestion detection techniques are disclosed in U.S. patentapplication Ser. No. 16/271,200, filed on Feb. 8, 2019, titled“TECHNIQUES FOR DETECTING AND MANAGING CONGESTION WITHIN A WORKSPACE”,the entire disclosure of which is herein incorporated by reference.

It should be appreciated that, in some embodiments, the obstaclemanagement engine may perform operations to identify congested volumesand/or the obstacle management engine may detect congestion byidentifying that congested volumes have already been identified (e.g.,by another system separate from the obstacle management engine).Supplemental data associated with the congested volumes may be generatedand/or obtained for each of the congested drives. Supplemental data of acongested volume may include any suitable combination of identifiers forMDUs currently located in the congested volume, identifier for MDUs thathave been within the congested volume over a threshold number of timeperiods, respective speeds associated with the MDUs within the congestedvolume, an average speed of the MDUs within the congested volume, or anysuitable information that describes the congestion within the congestedvolume. As used herein, obstacle information may be considered toinclude one or more congested volume identifiers and/or the supplementaldata associated with the congested volumes.

As another non-limiting example, the obstacle management engine mayobtain sensor data and/or navigational information initially provided bya number of MDUs of a workspace. The obstacle management engine mayidentify (e.g., utilizing image recognition techniques and/or known taskassignments and/or navigational information associated with each MDU,etc.) that the sensor data and/or navigational information indicate anobstacle (e.g., a fallen object) at a specific location and/or area ofthe workspace.

In some embodiments, the obstacle management engine may identify one ormore restricted spaces of the workspace. These restricted spaces mayeach be another example of an obstacle. A restricted space may beidentified by the system in any suitable manner (e.g., user defined,identified based on a schedule, identified based at least in part onstored data that identifies the restricted spaces of a workspace, etc.).

In some embodiments, the obstacle management engine may be configured toperform one or more remedial actions based at least in part on theobstacles identified and their corresponding obstacle information (e.g.,the location/area associated with the obstacle, the type associated withthe obstacle (e.g., fallen object, liquid, restricted space, congestion,etc.)). A remedial action may be any suitable combination of: providinga notification that the obstacle is occurring, causing modification ofat least one planned path corresponding to at least one of the MDUs,cancelling a task, reassigning a task, and/or causing at least one pathto be newly generated for at least one of the MDUs of the workspacebased at least in part on one or more of the obstacles identified withinthe warehouse.

In some embodiments, the obstacle management engine may generate andstore obstacle information (e.g., the sensor data, any suitablenavigational information, a location/area associated with the obstacle,information defining a restricted space, a type of obstacle (e.g.,congestion, fallen object, liquid, restricted space, etc.). In responseto detecting the obstacle, the obstacle management engine may determine,based at least in part on planned paths associated with the MDUs of theworkspace, a number of MDUs having tasks/planned paths that are affectedby the obstacle (e.g., the obstacle overlaps and/or intersects alocation and/or area of the planned path (including the current locationof the MDU)). In some embodiments, the task and/or planned path may onlybe affected if the obstacle overlaps and/or intersects a location and/orarea of the planned path that has not yet been executed. The obstaclemanagement engine may request, from a path planning module of themanagement system, a new path for each task affected. In someembodiments, the obstacle management engine may filter out at least oneof the affected tasks prior to requesting new paths.

For example, the obstacle management engine may whether or not anobstacle is detected at a source location or destination locationassociated with a planned path, or at a current location of the MDU. Ifthe obstacle is detected at one of these locations, the task may bereassigned and/or cancelled based at least in part on the typeassociated with the obstacle and/or any suitable attribute associatedwith the obstacle (e.g., type, size, shape, duration of existence,etc.). For example, a fallen object located at a destination location ofthe planned path may cause the task to be reassigned and/or cancelledentirely, while congestion occurring at the destination location maynot. In some embodiments, new paths may not be requested for tasks thathave already been reassigned and/or cancelled.

A request for a new path may be submitted for the remaining affectedpaths. The path planning module may be configured to attempt generationof a new path for each request while taking into account the obstacleinformation associated with known obstacles. Response data (e.g., a newpath for the MDU, a denial of the request, etc.) may be provided to theobstacle management engine for further processing.

In some embodiments, the obstacle management engine may determinewhether utilizing the originally planned path (the current path) of theMDU is “infeasible.” Utilizing the originally planned path may beconsidered to be “infeasible” when a delay (or other cost) incurred byexecuting the originally planned path exceeds a predeterminedinfeasibility threshold due to a detected obstacle. For example, thepredetermined infeasibility threshold may be 15 minutes. In someembodiments, the obstacle management engine may generate a metric (e.g.,an estimated completion time) that identifies a time of completion forthe task should the planned path be utilized for task execution in lightof the obstacle detected. In some embodiments, a task completion timethat was determined before the obstacle was detected (herein referred toas the “original task completion time”) may be compared to the estimatedtask completion time that is calculated based at least in part on theobstacle detected (herein referred to as the “obstacle-based taskcompletion time”). If the obstacle-based task completion time exceedsthe original task completion time by at least the predeterminedinfeasibility threshold, then executing the task utilizing the plannedpath may be considered “infeasible.”

In situations in which utilizing the planned path has been determined tobe infeasible, and the response data indicates a denial of the request(e.g., a new path was unavailable, etc.), the obstacle management enginemay transmit any suitable data to any suitable module of the workspacemanagement module in order to cause the task assigned to the MDU to bereassigned to a different MDU or cancelled altogether.

As another example, if a new path was provided in the response data, theobstacle management engine may generate a metric for the new path thatidentifies a time of completion for the task should the new path beutilized for task execution (herein referred to as a “new pathcompletion time”). In some embodiments, if a comparison of the new pathcompletion time to the original task completion time exceeds theinfeasibility threshold, the obstacle management engine may transmit anysuitable data to any suitable module of the workspace management modulein order to cause the task assigned to the MDU to be reassigned to adifferent MDU or cancelled altogether. Thus, if utilizing the plannedpath is determined to be infeasible and utilizing the new path is alsodetermined to be infeasible, the task may be reassigned or cancelled.

In some embodiments, if utilizing the planned path is determined to beinfeasible, but utilizing the new path is not infeasible (e.g., the newpath completion time is less than the original completion time of theplanned path, or at least does not exceed the original completion timeby over the infeasibility threshold, etc.), the obstacle managementengine may associate the task with an “Alternate_Feasible_Path” label.In some embodiments, the obstacle management engine, through thisassociation or otherwise, may cause the MDU assigned to the task toexecute the task utilizing the new path. The obstacle management enginemay perform any suitable operations to cause the MDU to commenceexecution of the task utilizing the new path such as transmitting thetask, the label, and/or the new path to the MDU and/or to the workspacemanagement module.

In some embodiments, the obstacle management engine may determine that,although utilizing the planned path is not infeasible, utilizing the newpath may result in a completion time that is less than theobstacle-based completion time and/or original completion time of theplanned path by at least a predetermined cost threshold amount.Accordingly, the obstacle management engine may determine that the newpath is a cheaper alternative to the planned path. In some embodiments,the obstacle management engine may store an association of the new pathand the MDU with a classification label indicating that a cheaper pathexists (e.g., “Cheaper_Path_Available”). In some embodiments, theobstacle management engine may update a corresponding task (e.g., a taskassignment assigned to the MDU) to indicate the classification labeland/or the new path. Any suitable combination of the task assignment,classification label, and/or new path may be provided to the MDU and/orworkspace management module. The MDU and/or the workspace managementmodule may perform any suitable operations to determine whether or notto cause the MDU to execute the task utilizing the new path.

In some embodiments, if utilizing the planned path is feasible (e.g.,not infeasible) and utilizing the new path is not cheaper than theplanned path by at least the cost threshold amount, the obstaclemanagement engine may ignore the new path and the MDU may continueexecuting the task utilizing the planned path.

It should be appreciated that the workspace management module (e.g., aroute planning module of the workspace management module) may beconfigured to utilize the obstacle information generated above whendetermining planned paths for the MDUs. That is, once an obstacle isdetected (e.g., by the obstacle management engine), any subsequentlypath may be generated such that the obstacle is avoided. In someembodiments, based on sensor data and/or navigational information, theobstacle management engine may identify that a previously detectedobstacle no longer exists. In these embodiments, the obstacleinformation may be deleted or otherwise ignored for subsequent pathplanning operations. In some embodiments, a similar process ofdetermining affected MDUs and requesting new path, determining metricsfor planned/new paths, identifying a remedial action based on thecomparison, and the like, may be executed not only when obstacles aredetected (or at least new obstacles are detected), but also whenpreviously detected obstacles are determined to no longer exist.

It should be appreciated that the techniques discussed above areapplicable in contexts other than inventory situations. The techniquesdisclosed herein provide, at least, a system and method detecting and/oravoiding obstacles within a workspace. Utilizing the techniquesdescribed herein, the inventory system may be configured to respond toever changing conditions within the workspace. The inventory system mayoperate more efficiently with respect to the MDUs/user devices operatingwithin facility as task completion delays may be reduced by identifyingobstacles within the facility and causing one or more remedial actions(e.g., determining alternative path(s), altering previously assignedpaths, ensuring future paths avoid such obstacles, cancelling and/orreassigning tasks, etc.) to be performed based at least in part on theobstacles identified. In some embodiments described herein, obstaclesthat have not yet occurred (e.g., future congestion) may be identifiedand utilized in path planning efforts to avoid obstacles that have notyet physically transpired.

Embodiment of the present invention may provide numerous benefits overprevious techniques. Conventional path planning techniques employ agreedy approach for planning paths that does not take into account thepath plans being executed by other MDUs. Additionally, it may be thecase that in conventional systems, a component (e.g., an MDU) may firstexperience an obstacle first hand (e.g., the obstacle affects a nextstep in task execution) before any remedial action may be executed. Thismay increase the delay in task completion while the MDU waits at theobstacle. The techniques provided herein ensure that, regardless of theparticular manner in which the obstacle is detected (e.g., via sensordata and/or navigational information of the MDU, a different MDU, asensor separate from the MDU), any suitable number of MDUs of theworkspace may benefit from the obstacle being known, without each MDUhaving to experience the obstacle first hand. Still further, futurepaths that are generated after the obstacle is known may be generated soas to take into account the location/areas of known obstacles. Asareas/locations are recovered within the workspace (e.g., due todetecting a previously known obstacle no longer exists), currentand/future paths may be modified/generated utilizing such information.Through utilizing these techniques, efficient use of the workspace maybe optimized and wasteful processing may be avoided, thus, providingnumerous improvements over conventional methods.

FIG. 1 is a schematic diagram illustrating an example environment 100suitable for implementing aspects of an obstacle management engine 103,in accordance with at least one embodiment. The environment 100 mayinclude a workspace management module 102 and one or more mobile driveunits (MDUs) (e.g., the MDUs 104-1, 104-2, 104-3, 104-4, 104-5,collectively referred to as “MDUs 104”) operating within a workspace 106(e.g., a sortation facility where items are sorted, or the like).Although workspace 106 may be depicted in FIG. 1 as a sortationfacility, it should be appreciated that the techniques described hereinmay apply to other contexts (e.g., a storage facility, a warehouse,etc.).

The workspace management module 102 may be configured to manage varioustask assignments and navigational aspects of the MDUs 104 with theworkspace 106. Each of the MDUs 104 may be configured to move itemswithin the workspace 106. Additional elements within the workspace 106may include one or more of the receptacles 112. In some embodiments, theworkspace 106 may include transfer areas (not depicted) where items maybe obtained by the MDUs 104 and conveyed to various delivery locations(e.g., receptacles 112). It should be appreciated that the workspace 106may include additional elements and/or components not depicted in FIG.1.

The receptacles 112 may be in various forms. By way of example only, thereceptacles 112 may be in any suitable form and configured to receiveone or more items. Some of the receptacles 112 may include storagelocations and/or containers configured to receive and store one or morephysical items. For example, the receptacles 112 may include bins,shelves, racks, or the like. In some examples, the receptacles 112 mayinclude an opening through which items may be deposited (and potentiallytransported or directed) to a storage container (e.g., a portablestorage container, a stationary storage container, etc.).

As a non-limiting example, the workspace 106 may include an elevatedfloor upon which the MDUs 104 may operate. The receptacles 112 mayinclude an opening within the elevated floor of workspace 106 throughwhich items may be deposited by the MDUs 104. In some examples, thefloor may or may not be elevated and the receptacles 112 may include anopening (e.g., directed upward or downward) through which items may bedeposited. Storage containers (not depicted) may be placed near to(e.g., below, above, etc.), or may otherwise be attached to, thereceptacles 112. An item may be deposited into the receptacles 112 andtransported (e.g., via a shoot, a conveyor belt, anotherMDU/transportation device, or the like) to a storage container (e.g., abin, a crate, a vehicle, or the like). The storage container may storethe item on a temporary or permanent basis. Each of the receptacles 112may be associated with an identifier that identifies a particularreceptacle from the group.

As another non-limiting example, the receptacles 112 may include astorage container on which one or more items may be placed fortemporary, permanent, or semi-permanent storage. The receptacles 112 maybe a shelving system and/or a storage container having any suitablenumber of storage containers within which the MDUs 104 may place variousitems. Each storage container within the receptacles 112 may beassociated with an identifier that identifies the particular storagecontainer within the receptacles 112.

In some embodiments, the MDUs may transport any item (e.g., a physicalitem, the receptacles 112, etc.) between locations within the workspace106. Accordingly, each of the MDUs 104 may be capable of moving itemsbetween locations within the workspace 106 to facilitate the entry,processing, sortation, storage management, and/or removal of itemswithin the workspace 106 and the completion of other tasks involvingitems.

In at least one embodiment, the workspace management module 102 mayassign tasks to appropriate components of workspace 106 (e.g., the MDUs104) and coordinate operation of the various components in completingthe tasks. Although shown in FIG. 1 as a single, discrete component, theworkspace management module 102 depicted may represent multiplecomponents and may represent or include portions of the MDUs 104 orother components of the environment 100. The workspace management module102 may be internal or external to the workspace 106. In some examples,the workspace management module 102 may be communicatively connected tovarious components of the environment 100 via one or more networks(e.g., the Internet, a wireless network, a local area network, acellular network, or the like).

The MDUs 104 may represent any devices or components appropriate for usein the workspace 106 based on the characteristics and configuration ofthe receptacles 112 and/or other components of workspace 106. In aparticular embodiment of environment 100, the MDUs 104 representindependent, self-powered devices configured to freely move about theworkspace 106. Examples of such inventory systems are disclosed in U.S.Pat. No. 9,087,314, issued on Jul. 21, 2015, titled “SYSTEM AND METHODFOR POSITIONING A MOBILE DRIVE UNIT” and U.S. Pat. No. 8,280,547, issuedon Oct. 2, 2012, titled “METHOD AND SYSTEM FOR TRANSPORTING INVENTORYITEMS”, the entire disclosures of which are herein incorporated byreference. The MDUs 104 may be communicatively coupled to the workspacemanagement module 102 via any suitable communication means and accordingto any suitable communications protocol. It should be appreciated thatthe examples described herein, may similarly be utilized by any suitabledevice that is configured to utilize space to move, regardless ofwhether or not it is able to freely move about the workspace 106. Thus,the obstacle detection and avoidance techniques herein may equally beapplied to devices other than MDUs, such as computing devices (e.g.,computing devices operated by a user), robotic arms, for example.

The workspace 106 of FIG. 1 represents an area within which the MDUs 104can move. For example, the workspace 106 may represent all or part ofthe floor of a mail-order warehouse and/or a sortation facility in whichthe MDUs 104 operate. Although FIG. 1 shows, for the purposes ofillustration, a workspace 106 that includes a fixed, predetermined, andfinite physical space, the workspace 106 may have variable dimensionsand/or an arbitrary geometry. While FIG. 1 is intended to illustrate aparticular embodiment in which the workspace 106 is entirely enclosed ina building, the workspace 106 may be unconstrained by any fixedstructure.

In operation, the workspace management module 102 may select particularMDUs of the MDUs 104 to perform particular tasks. Once a task (or manytasks) are assigned, the workspace management module 102 may provideinstructions to the MDUs 104. A task and instructions may include one ormore sub-tasks. By way of example only, a task of storing a newlyreceived item may include navigating to a particular location (e.g., atransfer area (not depicted), a particular receptacle of the receptacles112, etc.) and travelling (e.g., along a planned path) to anotherlocation (e.g., another area of the workspace 106, one of thereceptacles 112, etc.).

The MDUs 104 may be configured to receive task assignments (e.g., fromthe workspace management module 102 directly, or indirectly. The MDUs104 may transmit instruction requests (e.g., to the workspace managementmodule 102) and receive instruction responses (e.g., from the workspacemanagement module 102). An instruction request may include navigationalinformation associated with a particular MDU such as a locationidentifier indicating a current location of the MDU. An instructionresponse may include information that instructs the MDU to performparticular operations (e.g., begin traveling along a particular headingat a particular speed). The workspace management module 102 may beconfigured to manage space reservation to the MDUs 104 within theworkspace 106. In some embodiments, the workspace management module 102may reserve space (e.g., a volume, an area, a location, etc.) within theworkspace 106 for a particular MDU to execute some suitable portion ofits assigned task.

In some embodiments, the workspace 106 may employ fiducial markers 114that are placed within the workspace 106. The fiducial markers 114 canbe embedded in a concrete floor of the workspace 106, or alternativelyin a raised floor or supplemental surface disposed over an existingfloor surface. The fiducial markers 114 can be distributed (e.g., in agrid-like pattern, in any suitable manner) throughout the workspace 106and may encode location information via any suitable method (e.g., alocation identifier encoded in a bar code, a QR code, MaxiCode, DataMatrix, EZ Code, or any suitable identifying tag or code may beemployed, encoded or not).

As the MDUs 104 travel about the workspace 106, The MDUs 104 may beconfigured to obtain location information (e.g., via a sensor such as abar code reader, a scanner, an image capture device, etc.) from thefiducial markers 114. Any suitable number of fiducial markers 114 may beutilized and the markers may be situated in any suitable configurationdepending on the workspace in which they are utilized. In someembodiments, the MDUs 104 may be configured to determine locationinformation via methods that do not include the fiducial markers 114. Byway of example, the MDUs 104 may include a global positioning devicewhich is capable of providing a location of the MDU. As another example,the MDUs 104 may utilize a camera or other suitable sensor for capturingan image of the workspace and determine location information based atleast in part on analyzing the image according to any suitable imagerecognition techniques (e.g., to estimate location based on landmarksand/or markings identified within the image).

In some embodiments, the MDUs 104 may provide navigational informationincluding current location, current state, current speed, planned speed,current heading, and/or other characteristics of the MDUs 104 to theworkspace management module 102 to provide updated awareness of thetasks and location of the MDUs 104. In some embodiments, an MDU mayprovide this navigational information periodically and/or incrementallyto notify the workspace management module 102 of its location and/or acompletion or delay associated with a portion of its assigned task. Asthe MDUs 104 travel about the workspace 106, sensor data may becollected by one or more sensors of the MDU. This sensor data mayinclude obstacle information (e.g., an image of an obstacle in theworkspace, sensor reading indicating a physical object that was notpreviously planned to be at a particular location, congestion of one ormore MDUs within a sub-area of the workspace, etc.). By way of example,an MDU of the workspace 106 may provide obstacle information (e.g.,sensor data) related to obstacle 117 (e.g., a fallen object on theworkspace floor). Utilizing the sensor data, the obstacle managementengine 103 may be configured to detect the location and existence of theobstacle 117.

In some embodiments, the obstacle management engine 103 may be utilizedto identify an area of congestion 118. By way of example, the obstaclemanagement engine 103 (e.g., operating as part of the workspacemanagement module 102 or operating, at least in part, as a separatemodule) may utilize navigational information provided by the MDUs toidentify obstacle information associated with one or more congestedareas (e.g., area of congestion 118) of the workspace 106. By way ofexample, the obstacle management engine 103 may be configured toidentify the area of congestion 118 based at least in part on one ormore instances of historically provided navigational informationcorresponding to one or more historic time periods (e.g., 10-20 secondsof the last minute, 20-40 seconds of the last minute, 40-60 seconds ofthe last minute). Alternatively, the area of congestion 118 may beidentified by the obstacle management engine 103 utilizing planned pathdata indicating future locations of the MDUs 104 within one or morefuture time periods. In some embodiments, the obstacle management engine103 may generate supplemental data describing various attributes of thearea of congestion 118. Congested volume identifiers and correspondingsupplemental data may be an example of obstacle information. In someembodiments, the obstacle management engine 103 may be configured toperform one or more remedial actions based at least in part on theidentification of the area of congestion 118 and/or the supplementaldata associated with the area of congestion 118.

The obstacle management engine 103 may be configured to utilize thenavigational information and/or obstacle information provided by theMDUs 104 (or provided and/or generated by another module of the system)corresponding to any suitable obstacle (e.g., the obstacle 117, the areaof congestion 118, etc.) to determine and/or modify planned paths,update task assignment, or any suitable operation related to taskassignment and navigation of the MDUs 104 within the workspace 106. Insome embodiments, the navigational information and/or obstacle may bestored for additional processing or provided to any suitable componentof the system.

FIG. 2 is a schematic diagram 200 illustrating techniques for performinga remedial action in response to obstacle detection, in accordance withat least one embodiment. In some embodiments, the obstacle managementengine 103 may be configured to detect an area of congestion 202 as anobstacle.

For example, the MDU 104-1 may be assigned a task within the workspace204 (an example of the workspace 106 of FIG. 1, a sub-area of theworkspace 106, etc.). At any suitable time, sensor data and/ornavigational information provided by the MDUs 104 (e.g., the MDUs 104-1,104-2, 104-3, 104-5, and 104-6) may be obtained by the obstaclemanagement engine 103. In some embodiments, the obstacle managementengine 103 may generate a grid of volumes corresponding to various subportions of the workspace 204. Each volume may overlap one or more othervolumes and the grid of volumes may be generated to cover the entireworkspace. The obstacle management engine 103 may perform operations togenerate, utilizing the navigational data obtained, density values foreach of the volumes of the grid. A current density value for each volumemay be generated to indicate a number of MDUs currently within an areaassociated with the given volume. In some embodiments, a set of one ormore historic density values may be generated for each volumecorresponding to a number of historic time periods (e.g., 0-20 secondsof the last minute, 20-40 seconds of the last minute, 40-60 of the lastminute, etc.). In some embodiments, another set of one or more futuredensity values may be generated for each volume corresponding to anumber of future time periods (e.g., 0-10 seconds in the future, 10-20seconds in the future, etc.). The future density values may be generatedby the obstacle management engine 103 based at least in part on plannedpath data associated with any suitable number of the MDUs in theworkspace 204. The obstacle management engine 103 may be configured toexecute a protocol set utilizing the current density value, one or morehistoric density values, and/or one or more future density valuesassociated with a given volume to determine when a volume has become (orwill become) congested. Examples of congestion detection techniques aredisclosed in U.S. patent application Ser. No. 16/271,200, filed on Feb.8, 2019, titled “TECHNIQUES FOR DETECTING AND MANAGING CONGESTION WITHINA WORKSPACE”, the entire disclosure of which is herein incorporated byreference.

In the example depicted in FIG. 2, obstacle management engine 103 mayutilize these techniques to detect area of congestion 202 (e.g., basedon determining that a volume corresponding to area of congestion 202 hasbecome congested, or will become congested). Based at least in part ondetecting the area of congestion 202, the obstacle management engine 103may be configured to identify one or more tasks associated with one ormore MDUs of the workspace 204 which may be affected by the area ofcongestion 202. As a non-limiting example, the obstacle managementengine 103 may obtain planned path data for each MDU/task in theworkspace 204. The planned path data may be utilized, along with thelocation/area of the area of congestion 202, to identify that the taskcurrently being executed utilizing planned path 206 associated with MDU104-1 is affected by the area of congestion 202. Similarly, the obstaclemanagement engine 103 may determine that the planned path 208 associatedwith MDU 104-5 is unaffected by the area of congestion 202. In someembodiments, the obstacle management engine 103, upon detecting the areaof congestion 202 may generate and/or store obstacle informationcorresponding to the area of congestion 202 for utilization by theworkspace management module 102 (e.g., for determining future plannedpaths for any suitable number of MDUs of the workspace 204).

For each planned path determined to be affected by the obstacle(s)(e.g., the planned path 206), the obstacle management engine 103 mayrequest from the workspace management module 102, a new path for eachaffected MDU (e.g., the MDU 104-1). In response to one or more requests,the workspace management module 102 may be configured to attempt newpath generation for each MDU affected by the area of congestion 202. Inthe example depicted, the workspace management module 102 (or anysuitable module of the workspace management module 102) may attemptgeneration of a new path (e.g., new path 212) for MDU 104-1. As part ofthe process for generating a new path, the workspace management module102 may obtain obstacle information generated/stored by the obstaclemanagement engine 103 (e.g., obstacle information corresponding to oneor more obstacles detected within the workspace 204 including obstacleinformation corresponding to the area of congestion 202). The workspacemanagement module 102 may generate response data including a new pathgenerated (e.g., the new path 212) or an indication that the request wasdenied (indicating that a new path could not be generated in light ofthe obstacles within the workspace 204). Response data (e.g., indicatinga new path 212 for the MDU, or indicating that a new path could not begenerated for MDU 104-1, etc.) may be provided to the obstaclemanagement engine 103 for further processing.

In some embodiments, the obstacle management engine 103 may determinewhether the task is feasible or infeasible based at least in part onexecuting planned path 206 in light of the area of congestion 202. Forexample, the obstacle management engine 103 may calculate a metric(e.g., an obstacle-based completion time associated with task executionutilizing the planned path 206 in light of the area of congestion 202.If the obstacle management engine 103 determines that difference betweenthe original completion time of the planned path 206 and anobstacle-based completion time of the planned path 206 does not exceedthe predetermined infeasibility threshold, then executing the taskutilizing the planned path 206 may be considered “feasible.”Alternatively, if the difference between the original completion time ofthe planned path 206 and an obstacle-based completion time of theplanned path 206 (e.g., indicating a completion time of the planned path206 due to the obstacle) is equal to or exceeds the predeterminedinfeasibility threshold, then executing the task utilizing the plannedpath 206 may be considered “infeasible.”

In situations in which utilizing the planned path 206 has beendetermined to be infeasible, and the response data indicates a denial ofthe request (e.g., a new path was unavailable, etc.), the obstaclemanagement engine 103 may transmit any suitable data to any suitablemodule of the workspace management module 102 in order to cause the taskassigned to the MDU 104-1 to be reassigned to a different MDU in theworkspace 204 or cancelled altogether.

If new path 212 was provided in the response data, the obstaclemanagement engine may generate a metric for the new path 212 thatidentifies a time of completion for the task should the new path 212 beutilized for task execution (herein referred to as a “new pathcompletion time”). In some embodiments, if a comparison of the new pathcompletion time to the original task completion time exceeds apredetermined infeasibility threshold, the obstacle management engine103 may transmit any suitable data to any suitable module of theworkspace management module 102 in order to cause the task assigned tothe MDU 104-1 to be reassigned to a different MDU or cancelledaltogether. Thus, if utilizing the planned path 206 is determined to beinfeasible and utilizing the new path 212 is also determined to beinfeasible, the task may be reassigned or cancelled.

In some embodiments, if utilizing the planned path 206 is determined tobe infeasible, but utilizing the new path 212 is not infeasible (e.g.,the new path completion time is less than the original completion timeof the planned path, or at least does not exceed the original completiontime by over the infeasibility threshold, etc.), the obstacle managementengine 103 may cause the task assigned to MDU 104-1 to be associatedwith an “Alternate_Feasible_Path” label (or a similar label). In someembodiments, the obstacle management engine 103, through thisassociation or otherwise, may cause the MDU 104-1 assigned to the taskto execute the task utilizing the new path 212. The obstacle managementengine 103 may perform any suitable operations to cause the MDU 104-1 tocommence execution of the task utilizing the new path 212 such astransmitting the task, the label, and/or data defining the new path 212to the MDU and/or to the workspace management module 102.

In some embodiments, the obstacle management engine 103 may determinethat, although utilizing the planned path 206 is not infeasible,utilizing the new path 212 may result in a completion time that is lessthan the obstacle-based completion time and/or original completion timeof the planned path 206 by at least a predetermined cost thresholdamount. Accordingly, the obstacle management engine 103 may determinethat executing the new path 212 is a cheaper alternative to executingthe planned path 206. In some embodiments, the obstacle managementengine 103 may store an association of the new path 212 and the MDU104-1 with a classification label indicating that a cheaper path exists(e.g., “Cheaper_Path_Available”). In some embodiments, the obstaclemanagement engine 103 may update a corresponding task (e.g., a taskassignment) to indicate the classification label and/or the new path 212and/or data defining the new path 212. Any suitable combination of thetask assignment, classification label, and/or data defining the new path212 may be provided to the MDU 104-1 and/or workspace management module102. The MDU 104-1 and/or the workspace management module 102 mayperform any suitable operations to determine whether or not to cause theMDU 104-1 to execute the task utilizing the new path 212.

In some embodiments, if utilizing the planned path 206 is not infeasibleand utilizing the new path 212 is not cheaper than the planned path byat least the cost threshold amount, the obstacle management engine 103may ignore the existence new path 212 and the MDU 104-1 may continueexecuting the task utilizing the planned path 206.

It should be appreciated that changes in completion times (a differencebetween the respectively completion times for executing the planned path206 and the new path 212) are utilized as an example only. It iscontemplated that other changes and/or differences between executing theplanned path and the new path may be utilized. When determining whetheror not the new path 212 should be executed in lieu of the planned path206, the obstacle management engine 103 may utilize any suitablecombination of parameters such as a priority of the task, a distancebetween the current location of the MDU and the destination location forthe task, whether or not the task corresponds to conveyance of an item,a priority associated with the item (e.g., expedited shipping of theitem), any suitable parameter associated with the task, a determinationthat one or more other planned paths would need to be altered in theworkspace 204 should new path 212 be utilized, a determination thatexecuting the new path 212 may create a new obstacle (e.g., based onfuture congestion), and the like.

In some embodiments, the obstacle management engine 103 may determineone or more remedial actions to execute. For example, the obstaclemanagement engine 103 may provide a notification (e.g., an email, a textmessage, an audible alert, a push notification, etc.) to one or morenetwork pages and/or user computing devices to indicate the existence ofthe obstacle. As another example of a remedial action, the obstaclemanagement engine 103 may transmit the new path and/or theclassification label to the MDU 104-1 to cause the planned path of theMDU 104-1 to be altered. By way of example, the obstacle managementengine 103 may transmit data defining the new path 212 to the MDU 104-1which may cause the MDU 104-1 to begin executing the new path 212. Asanother example, the obstacle management engine 103 may transmit atleast the classification label or another indicator corresponding to theclassification label that, upon receipt, may cause the MDU 104-1 torequest a new path from the workspace management module 102. As anotherexample, the obstacle management engine 103 may store the classificationlabel, new path, and/or any suitable obstacle information within a datastore accessible to one or more modules of the workspace managementmodule 102 in order to cause the workspace management module 102 toperform, at any suitable time, one or more operations.

In some embodiments, the workspace management module 102 may utilizeobstacle information provided/stored by the obstacle management engine103 (e.g., obstacle information corresponding to the area of congestion202) when generating paths for MDUs that have been assigned new taskssubsequent to the detection of the obstacle(s). For example, MDU 104-3may not have been assigned a task when the area of congestion 202 wasdetected, or may have been assigned a new task since the area ofcongestion 202 was detected. The workspace management module 102 may beconfigured to utilize the obstacle information associated with the areaof congestion 202 (and any other known obstacle information) to generatepath 214. The workspace management module 102 may utilize the obstacleinformation such that the path 214 is generated to avoid any knownobstacles (e.g., the area of congestion 202).

It should be appreciated that although the obstacle depicted in FIG. 2as an area of congestion, the same techniques described above may beutilized for any suitable type of obstacle detected. By way of example,rather than detecting an area of congestion, the obstacle managementengine 103 may detect (e.g., utilizing sensor data and/or navigationalinformation provided by one or more MDUs) that an obstacle exists at aspecific location and/or within an area of the workspace 204. As anon-limiting example, an MDU passing by a fallen object may collectsensor data indicating the existence of the fallen object at a specificlocation on the floor of the workspace 204. As another example, theobstacle management engine 103 may identify a restricted space of theworkspace. Accordingly, the techniques described above may be similarlyperformed utilizing obstacle information associated with the fallenobject or the restricted space rather than the area of congestion 202.

FIG. 3 is a schematic diagram 300 illustrating additional techniques forperforming a remedial action in response to obstacle detection, inaccordance with at least one embodiment. Continuing on with the exampleof FIG. 2, it may be the case that the obstacle management engine 103may determine that obstacle 302 exists within the workspace 304 (e.g.,the workspace of 204 of FIG. 2). The existence of the obstacle 302 maybe determined utilizing any suitable combination of sensor data and/ornavigational information provided by any suitable number of MDUs withinthe workspace 304 and/or by identifying a restricted area of theworkspace.

For example, an MDU (not depicted) traveling near the obstacle 302 maycollect any suitable sensor data associated with the location of theobstacle 302 utilizing one or more sensors (e.g., digital cameras, videocameras, infrared sensors, thermal sensors, RFID scanners and/or tags,etc.) affixed to the MDU. In some embodiments, one or more sensorssituated at a location 306 of the workspace 304 may collect sensor dataindicating the existence of the obstacle 302. By way of example only, anMDU with a camera and/or a camera situated at location 306 may provideone or more images (sensor data) to the obstacle management engine 103that depict a fallen object on the floor of the workspace 304. Theobstacle management engine 103 may detect (e.g., utilizing any suitableimage recognition techniques, the task assignments of the MDUs, thelocations of the MDUs within the workspace 304, or any suitable data) todetermine that the fallen object is an obstacle (e.g., a condition thatis not supposed to be occurring with the workspace 304).

The obstacle management engine 103 may be configured to determine alocation associated with the sensor collector (e.g., a location of theMDU as identified in navigational information provided by the MDU, thelocation 306 as being associated with a camera, etc.). Utilizing thesensor data and the location associated with the sensor collector, theobstacle management engine 103 may identify a location associated withthe obstacle 302. The obstacle management engine 103 may generateobstacle information (e.g., indicating a type of obstacle, the locationand/or area of the obstacle, or any suitable information describing anysuitable aspect of the obstacle) and may store this obstacle informationin a data store configured to store such information and/or the obstaclemanagement engine 103 may provide the obstacle information to anysuitable component of the system (e.g., the workspace management module102, the MDU 104-1, any suitable MDU of the workspace 304, etc.).

In some embodiments, the obstacle 302 may correspond to a restrictedspace. The obstacle management engine 103 may consult restricted spacedata that identifies locations and/or areas that are restricted. In someembodiments, a restricted space may be user defined or predetermined.The restricted space may be restricted based at least in part on ascheduled day and/or time, or the restricted space may be persistent.

Continuing with the example provided in FIG. 2, the obstacle 302 may bedetected by the obstacle management engine 103 after execution of theassigned path 308 (e.g., new path 212 of FIG. 2) has been assigned tothe MDU 104-1. Obstacle 302 may be detected after obstacle 303 (e.g.,the area of congestion 202 of FIG. 2, a restricted area, or the like) isdetected.

In some embodiments, the obstacle management engine 103 may determinewhether or not the task should be reassigned and/or cancelled. In someembodiments, it may be the case that the effect of obstacle 303 hasalready been assessed (e.g., as described in FIG. 2).

Accordingly, in some embodiments, the obstacle management engine 103 mayignore the obstacle 303 due to having already performed operations toaddress the effects of the obstacle 303. With respect to obstacle 302,the obstacle management engine 103 may compare the location of theobstacle 302 to various locations of the assigned path 308. If theobstacle is detected at a source location or a destination location ofthe task, or at a current location of the MDU 104-1, then, depending onany suitable attribute of the obstacle (e.g., type, shape, area,duration of existence, etc.) the task may be reassigned and/orcancelled. For example, a fallen object located at a destinationlocation of the assigned path 308 may cause the task to be reassigned orcancelled while congestion occurring at the destination location maynot. In some embodiments, new paths may not be requested for tasks thathave already been reassigned or cancelled. In the example depicted inFIG. 3, the task assigned to MDU 104-1 is not reassigned or canceledbased at least in part on a determination that the obstacle 302 is notlocated at a source or destination location associated with the task, orat the current location of the MDU 104-1.

The obstacle management engine 103 may request a new path for MDU 104-1based at least in part on the determination that the task is affected bythe obstacle 302 (e.g., the obstacle 302 overlaps/intersects some(unexecuted) portion of the assigned path 308). The workspace managementmodule 102 (e.g., a path planning module of the workspace managementmodule 102) may be configured to attempt generation of a new path foreach request while taking into account the obstacle informationassociated with known obstacles (e.g., obstacles 302 and 303). Responsedata (e.g., a new path for the MDU, a denial of the request, etc.) maybe provided to the obstacle management engine for further processing.

In some embodiments, the obstacle management engine may determinewhether or not the assigned path 308 of the MDU is “infeasible,” thatis, a delay (or other cost) would be incurred by executing the taskutilizing the assigned path 308 exceeds a predetermined infeasibilitythreshold due to the obstacle 302. In some embodiments, the obstaclemanagement engine 103 may generate a metric (e.g., an estimatedcompletion time) that identifies a time of completion for the taskshould the assigned path 308 be utilized for task execution in light ofthe obstacle 302. In some embodiments, a task completion time that wasdetermined before the obstacle 302 was detected (herein referred to asthe “original task completion time”) may be compared to the estimatedtask completion time that is calculated based at least in part on theobstacle 302 (herein referred to as the “obstacle-based task completiontime”). If the obstacle-based task completion time exceeds the originaltask completion time by at least the predetermined infeasibilitythreshold, then executing the task utilizing the assigned path 308 maybe considered “infeasible.”

In situations in which the assigned path 308 has been determined to beinfeasible, and the response data indicates a denial of the request(e.g., a new path was unavailable, etc.), the obstacle management engine103 may transmit any suitable data to any suitable module of theworkspace management module 102 in order to cause the task assigned tothe MDU 104-1 to be reassigned to a different MDU or the task may becancelled altogether.

As another example, if a new path 310 was provided in the response data,the obstacle management engine 103 may generate a metric for the newpath 310 that identifies a time of completion for the task should thenew path 310 be utilized for task execution (herein referred to as a“new path completion time”). In some embodiments, if a comparison of thenew path 310 completion time to the original task completion time ofassigned path 308 exceeds the infeasibility threshold, the obstaclemanagement engine 103 may transmit any suitable data to any suitablemodule of the workspace management module 102 in order to cause the taskassigned to the MDU 104-1 to be reassigned to a different MDU or thetask may be cancelled altogether. Thus, if the assigned path 308 isdetermined to be infeasible and the new path 310 is also determined tobe infeasible, the task may be reassigned or cancelled.

In some embodiments, if the assigned path 308 is determined to beinfeasible, but the new path 310 is not infeasible (e.g., the new pathcompletion time is less than the original completion time of the plannedpath, or at least does not exceed the original completion time by overthe infeasibility threshold, etc.), the obstacle management engine 103may associate the task with an “Alternate_Feasible_Path” label. In someembodiments, the obstacle management engine, through this association orotherwise, may cause the MDU 104-1 assigned to the task to execute thetask utilizing the new path 310. The obstacle management engine mayperform any suitable operations to cause the MDU 104-1 to commenceexecution of the task utilizing the new path 310 such as transmittingthe task, the label, and/or data defining the new path 310 to the MDU104-1 and/or to the workspace management module 102.

In some embodiments, the obstacle management engine 103 may determinethat, although the assigned path 308 is not infeasible, the new path 310may result in a completion time that is less than the obstacle-basedcompletion time and/or original completion time of the assigned path 308by at least a predetermined cost threshold amount. Accordingly, theobstacle management engine 103 may determine that the new path 310 is acheaper alternative to the assigned path 308. In some embodiments, theobstacle management engine may store an association of the new path 310and the MDU 104-1 with a classification label indicating that a cheaperpath exists (e.g., “Cheaper_Path_Available”). By way of example, theobstacle management engine 103 may update a corresponding task (e.g., atask assignment for the MDU 104-1) to indicate the classification labeland/or the new path 310. Any suitable combination of the taskassignment, classification label, and/or data defining the new path 310may be provided to the MDU 104-1 and/or workspace management module 102.The MDU 104-1 and/or the workspace management module 102 may perform anysuitable operations to determine whether or not to cause the MDU 104-1to execute the task utilizing the new path 310.

In some embodiments, if executing the task with the assigned path 308 isnot infeasible and executing the task with the new path 310 is notcheaper than executing the task with the assigned path 308 by at leastthe cost threshold amount, the obstacle management engine 103 may ignorethe new path 310 and the MDU 104-1 may continue executing the taskutilizing the assigned path 308.

FIG. 4 is a block diagram illustrating an example method 400 forperforming at least one remedial action based at least in part onobstacle detection within a workspace, in accordance with at least oneembodiment.

At step 402, the existence of the obstacle 302 may be detected utilizingany suitable combination of sensor data and/or navigational informationprovided by any suitable number of MDUs within the workspace 204.

By way of example, MDUs within the workspace may collect any suitablesensor data utilizing one or more sensors (e.g., digital cameras, videocameras, infrared sensors, thermal sensors, RFID scanners and/or tags,etc.) affixed to the MDU. In some embodiments, one or more sensorsseparate from the MDUs and situated within the workspace may collectsensor data. By way of example only, an MDU with a camera and/or acamera situated within the workspace may provide one or more images(sensor data) to the obstacle management engine 103 that depict anobstacle (e.g., a puddle of water, a fallen object, a misplacedcontainer) within the workspace. The obstacle management engine 103 maydetect (e.g., utilizing any suitable image recognition techniques, thetask assignments of the MDUs, the current known locations of the MDUswithin the workspace (as determined by navigational data provided by theMDUs), or any suitable data) to determine that the sensor data indicatesan obstacle (e.g., a condition that is not supposed to be occurring withthe workspace).

The obstacle management engine 103 may be configured to determine alocation associated with the sensor collector (e.g., a location of theMDU as identified in navigational information provided by the MDU, thelocation associated with a camera, etc.). Utilizing the sensor dataand/or the location associated with the sensor collector, the obstaclemanagement engine 103 may identify a location associated with theobstacle. The obstacle management engine 103 may generate obstacleinformation (e.g., indicating a type of obstacle, the location and/orarea of the obstacle, or any suitable information describing anysuitable aspect of the obstacle) and may store this obstacle informationin obstacle information data store 404 and/or the obstacle managementengine 103 may provide the obstacle information to any suitablecomponent of the system (e.g., the path planning module 406, a componentof the workspace management module 102 of FIGS. 1-3).

In some embodiments, the obstacle may be detected based at least in parton navigational information provided by the MDUs of the system. Theobstacle management engine 103 may generate a grid of volumescorresponding to various sub portions of the workspace. These volumesmay include a set of vertical volumes and/or a set of horizontalvolumes. Each volume may overlap one or more other volumes and the gridof volumes may be generated to cover the entire workspace. The obstaclemanagement engine 103 may perform operations to generate density valuesfor each of the volumes of the grid, utilizing the navigationalinformation indicating locations of each MDU. A current density valuefor each volume may be generated to indicate a number of MDUs currentlywithin an area associated with the given volume. In some embodiments, aset of one or more historic density values may be generated for eachvolume corresponding to a number of historic time periods (e.g., 0-20seconds of the last minute, 20-40 seconds of the last minute, 40-60 ofthe last minute, etc.). In some embodiments, another set of one or morefuture density values may be generated for each volume corresponding toa number of future time periods (e.g., 0-10 seconds in the future, 10-20seconds in the future, etc.). The future density values may be generatedby the obstacle management engine 103 based at least in part on plannedpath data associated with any suitable number of the MDUs in theworkspace 204. The obstacle management engine 103 may be configured toexecute a protocol set utilizing the current density value, one or morehistoric density values, and/or one or more future density valuesassociated with a given volume to determine when a volume has become (orwill become) congested. When an area of current and/or future congestionis identified, the obstacle management engine 103 may be configured togenerate obstacle information that describes any suitable aspect of thecongestion (e.g., a location/area of the congestion, etc.) and store theobstacle information within the obstacle information data store 404.

At 408, the obstacle management engine 103 may be configured to updatepath planning operations for the workspace utilizing the obstacleinformation. In some embodiments, storing the obstacle information inthe obstacle information data store 404 may cause path planningoperations (e.g., performed by the path planning module 406) to utilizethe obstacle information when determining new paths for task execution.In some embodiments, the obstacle management engine 103 may beconfigured to provide an indication of the existence of the obstacles,or the obstacle information itself, directly to the path planning module406 to stimulate utilization of the obstacle information for pathplanning purposes. In other embodiments, the obstacle management engine103 may be configured to store an indication of the existence of theobstacles and/or the obstacle information in a data store accessible tothe path planning module 406 to cause the path planning module 406 toconsider the obstacle for subsequent path planning operations.

At 410, based at least in part on detecting the obstacle, the obstaclemanagement engine 103 may be configured to identify one or more tasksaffected by the detected obstacle. As a non-limiting example, theobstacle management engine 103 may obtain planned path data for each MDUin the workspace. The planned path data may be utilized, along with thelocation/area of the obstacle (e.g., a portion of the obstacleinformation), to identify that a particular planned path of a task isaffected by the obstacle. For example, the obstacle management engine103 may determine that a planned path will be affected due todetermining that the obstacle overlaps and/or intersects any suitableportion of the planned path (e.g., a portion of the planned path thathas not yet been executed by the corresponding MDU).

At 411, the obstacle management engine 103 may determine whether or notthe task is to be reassigned or cancelled altogether. As a non-limitingexample, the obstacle management engine 103 may determine a location ofthe obstacle corresponds to a source location (e.g., a location at whichthe task is commenced) or a destination location (e.g., a location atwhich a task is completed) associated with the task assigned to an MDU,or a current location of the MDU. If either the source location ordestination location of a task is determined to overlap with alocation/area of the obstacle, the obstacle management engine 103 maytransmit a request to reassign the task currently assigned to that MDUto another MDU in the workspace, or request that the task be cancelledaltogether. In some embodiments, the transmission of the request toreassign or cancel the task may depend on any suitable attribute (e.g.,type, area, shape, duration of existence, etc.) of the obstacleinvolved. By way of example, if the source location and/or thedestination location of the task overlaps the obstacle, and the obstacleis not congestion-based (e.g., a fallen object, a restricted space,etc.), a request for cancellation and/or reassignment may betransmitted. However, in some cases, even if the source location and/orthe destination location of the task overlaps the obstacle, a request toreassign or cancel the task may not be transmitted if the obstacle isassociated with a type indicating congestion. As yet another example, ifthe source location of the task, the destination location of the task,or a current location of the MDU overlap an obstacle that is arestricted area, a request for reassignment or cancellation of the taskmay be transmitted.

At 412, a request (or respective request) for at least some number ofthe affected paths may be submitted. By way of example, a request may besubmitted for each task that has been determined to be affected in lightof the obstacle. In some embodiments, if a request for reassignmentand/or cancellation of the task has already been transmitted, a requestfor a new path may not be submitted. In some embodiments, the pathplanning module 406 (or any suitable module of the workspace managementmodule 102 of FIGS. 1-3) may attempt generation of a new path for eachnew path request. As part of performing a process for generating a newpath, the path planning module 406 may obtain obstacle information fromthe obstacle management engine 103 and/or the obstacle information datastore 404. The workspace management module 102 may generate responsedata including a new path generated and/or an indication that therequest was denied (or that a new path could not be generated in lightof the obstacles within the workspace). Response data (e.g., indicatinga new path for the MDU, or indicating that a new path could not bedetermined for MDU 104-1, etc.) may be provided to the obstaclemanagement engine 103 for further processing.

At 414, the obstacle management engine 103 may perform a first set ofone or more remedial actions when a new path is not provided (e.g., whenresponse data indicates that a new path is unavailable and/or when thecorresponding request for a new path has been denied). The obstaclemanagement engine 103 may transmit any suitable data to any suitablemodule of the workspace management module 102 in order to cause the taskassigned to an MDU (e.g., MDU 104-1) to be reassigned to a different MDUin the workspace and/or cancelled altogether.

By way of example, the obstacle management engine 103 may determinewhether executing the task with the originally planned path (the currentpath) of the MDU is “infeasible,” that is, a delay (or other cost) wouldbe incurred by executing the originally planned path exceeds apredetermined infeasibility threshold as a result of one or moredetected obstacles. In some embodiments, the obstacle management enginemay generate a metric (e.g., an estimated completion time) thatidentifies a time of completion for the task should the planned path beutilized for task execution in light of the obstacle(s) detected. Insome embodiments, a task completion time that was determined before theobstacle(s) were detected (herein referred to as the “original taskcompletion time”) may be compared to the estimated task completion timethat is calculated based at least in part on the obstacle(s) detected(herein referred to as the “obstacle-based task completion time”). Ifthe obstacle-based task completion time exceeds the original taskcompletion time by at least the predetermined infeasibility threshold,then executing the task utilizing the planned path may be considered tobe “infeasible.”

In situations in which executing the task utilizing the planned path hasbeen determined to be infeasible, and the response data indicates adenial of the request (e.g., a new path was unavailable, etc.), theobstacle management engine 103 may transmit any suitable data to anysuitable module (e.g., the workspace management module 102) in order tocause the task assigned to the MDU to be reassigned to a different MDUor cancelled altogether.

At 416, the obstacle management engine 103 may perform a second set ofone or more remedial actions when a new path is provided/indicated inthe response data. If a new path was provided in the response data, theobstacle management engine 103 may generate a metric for the new paththat identifies a time of completion for the task should the new path beutilized for task execution (herein referred to as a “new pathcompletion time”). In some embodiments, if a comparison of the new pathcompletion time to the original task completion time exceeds theinfeasibility threshold, the obstacle management engine may transmit anysuitable data to any suitable module (e.g., the workspace managementmodule 102) in order to cause the task assigned to the MDU to bereassigned to a different MDU or cancelled altogether. Thus, ifexecuting the task utilizing the planned path is determined to beinfeasible and executing the task utilizing the new path is alsodetermined to be infeasible, the task may be reassigned or cancelled.

In some embodiments, if executing the task utilizing the planned path isdetermined to be infeasible, but executing the task utilizing the newpath is not infeasible (e.g., the new path completion time is less thanthe original completion time of the planned path, or at least does notexceed the original completion time by over the infeasibility threshold,etc.), the obstacle management engine 103 may associated the task withan “Alternate_Feasible_Path” label. In some embodiments, the obstaclemanagement engine 103, through this association or otherwise, may causethe MDU assigned to the task to execute the task utilizing the new path.The obstacle management engine 103 may perform any suitable operationsto cause the MDU to commence execution of the task utilizing the newpath such as transmitting the task, the label, and/or the new path tothe MDU and/or to the workspace management module 102 of FIGS. 1-3.

In some embodiments, the obstacle management engine 103 may determinethat, although executing the task utilizing the planned path is notinfeasible, executing the task utilizing the new path may result in acompletion time that is less than the obstacle-based completion timeand/or original completion time of the planned path by at least apredetermined cost threshold amount. Accordingly, the obstaclemanagement engine 103 may determine that utilizing the new path for taskexecution is a cheaper alternative to utilization of the planned path.In some embodiments, the obstacle management engine 103 may store anassociation of the new path and the MDU with a classification labelindicating that a cheaper path exists (e.g., “Cheaper_Path_Available”).In some embodiments, the obstacle management engine 103 may update acorresponding task (e.g., a task assignment) to indicate theclassification label and/or the new path. Any suitable combination ofthe task assignment, classification label, and/or new path may beprovided to the MDU and/or workspace management module. The MDU and/orthe workspace management module may perform any suitable operations todetermine whether or not to cause the MDU to execute the task utilizingthe new path.

In some embodiments, if utilizing the planned path for task execution isnot infeasible and execution the task utilizing the new path is notcheaper than utilization of the planned path by at least the costthreshold amount, the obstacle management engine 103 may ignoreexistence of the new path and the MDU may continue executing the taskutilizing the planned path.

It should be appreciated that completion times are utilized as anexample only. It is contemplated that a comparison between the plannedpath and the new path may be performed to identify which path mayprovide the greatest benefit. By way of example, the comparison mayutilize completion time and/or any suitable combination of parameterssuch as a priority of the task, a distance between the current locationof the MDU and the destination location for the task, whether or not thetask corresponds to conveyance of an item, a priority associated withthe item (e.g., expedited shipping of the item), any suitable parameterassociated with the task, a determination that one or more other plannedpaths would need to be altered in the workspace should new path beutilized, a determination that executing the new path may create a newobstacle (e.g., based on future congestion), and the like.

In some embodiments, the obstacle management engine 103 may, based onthe metrics generated above, determine one or more remedial actions toexecute. For example, the obstacle management engine 103 may provide anotification (e.g., an email, a text message, an audible alert, a pushnotification, etc.) to one or more network pages and/or user computingdevices to indicate the existence of the obstacle. As another example ofa remedial action, the obstacle management engine 103 may transmit thenew path and/or the classification label to the MDU 104-1 to cause theplanned path of the MDU 104-1 to be altered. As another example, theobstacle management engine 103 may transmit at least the classificationlabel or another indicator corresponding to the classification labelthat, upon receipt, may cause the MDU 104-1 to request a new path forits assigned task from the workspace management module 102. In someembodiments, a classification label of “Alternate_Feasible_Path” maycause the MDU 104-1 to execute the new path associated with the task. Aclassification label of “Cheaper_Path_Available” may cause the MDU 104-1to perform any suitable operations to opt to remain on the originallyplanned path or to execute the new/cheaper path available. In someembodiments, one or more metrics for the planned path and the new pathmay be provided (e.g., in the same message as the new path and/orclassification label) that indicate a difference in task executionbetween utilizing the planned path and utilizing the new path.Alternatively, the MDU 104-1 may be configured to generate these one ormore metrics. In some embodiments, the MDU 104-1 may be configured withcode that, when generated, causes the MDU 104-1 to select the plannedpath or the new path for execution based at least in part on themetric(s). According to some embodiments, the MDU 104-1 may transmit arequest to the workspace management module 102 to effectuate a changefrom the planned path to the new path. It should be appreciated that anysuitable combination of the new path, the first metric, the secondmetric, and/or the classification label may be transmitted to the MDUand/or a component of the workspace management module to effectuate achange in task execution.

As another example of a remedial action, the obstacle management engine103 may transmit (e.g., to any suitable component of the workspacemanagement module 102) and/or store any suitable combination of theclassification label, the originally planned path, the new path, a taskassignment, an MDU identifier, and/or any suitable obstacle informationwithin a data store accessible to one or more modules of the workspacemanagement module 102. In some embodiments, the path planning module 406(or any suitable module of the workspace management module 102) mayutilize this received and/or stored data to perform, at any suitabletime, one or more operations (e.g., operations for modifying a plannedpath assigned to an existing task, operations for generating and/orassigning a planned path to a new task, etc.).

For example, the path planning module 406 may utilize obstacleinformation provided/stored by the obstacle management engine 103 (e.g.,obstacle information of the obstacle information data store 404) whengenerating paths for MDUs within the workspace. In some embodiments, thepaths may be generated so as to avoid any known obstacles.

FIG. 5 is an example system architecture for implementing aspects of aninventory system 500, in accordance with at least one embodiment. Thearchitecture of the inventory system 500 may include a service providercomputer(s) 502. The service provider computer(s) 502 may support anelectronic marketplace (not shown) and interface with purchase anddelivery services of the electronic marketplace. In this manner, theservice provider computer(s) 502 may coordinate receiving, storing,packaging, shipping, and/or sorting of items in a workspace (e.g.,workspace 106 of FIG. 1) operated by, or on behalf of, the electronicmarketplace provider. In some examples, the service provider computer(s)502 may be a stand-alone service operated on its own or in connectionwith an electronic marketplace. In either example, the service providercomputer(s) 502 may be in communication with the mobile drive units 104via one or more network(s) 506 (hereinafter, “the network 506”). Thenetwork 506 may include any one or a combination of many different typesof networks, such as cable networks, the Internet, wireless networks,cellular networks, radio networks, and other private and/or publicnetworks.

Computing devices 508(1)-508(N) (hereinafter, “the computing device(s)508”) may also be in communication with the service provider computer(s)502 via the network 506. The computing device(s) 508 may be operable byone or more user(s) 510 (hereinafter, “the users 510”) to access theservice provider computer(s) 502 via the network 506. The computingdevice(s) 508 may be any suitable device capable of communicating withthe network 506. For example, the computing device(s) 508 may be anysuitable computing device such as, but not limited to, a mobile phone, asmart phone, a personal digital assistant (PDA), a laptop computer, athin-client device, a tablet PC, a desktop computer, a set-top box, orother computing device. The computing device(s) 508 may include similarcomponents provided in the onboard computer 512, including one or moreprocessors, memory, I/O devices, one or more data stores, additionalstorage, an operating system, and, in particular embodiments, amanagement module similar to the workspace management module 515. Insome embodiments, the computing device(s) 508 may be utilized tointeract with an electronic marketplace (e.g., an electronic marketplacehosted by the service provider computer(s) 502). In some embodiments,the computing device(s) 508 may be operated by one or more individualsworking with a workspace (e.g., the workspace 106). The functionalityprovided by the workspace management module 515 discussed below withrespect to the mobile drive unit(s) (MDU(s) 104) may similar be providedby a management module operating on a computing device(s) 508. Likewise,the functionality of management module 533 provided to the MDU(s) 104may similarly be provided by the computing device(s) 508.

Turning now to the details of the MDU(s) 104, the MDU(s) 104 may includean onboard computer 512 including at least one memory 514 and one ormore processing units (or processor(s)) 516. The processor(s) 516 may beimplemented as appropriate in hardware, computer-executableinstructions, software, firmware, or combinations thereof.Computer-executable instruction, software or firmware implementations ofthe processor(s) 516 may include computer-executable ormachine-executable instructions written in any suitable programminglanguage to perform the various functions described. The memory 514 mayinclude more than one memory and may be distributed throughout theonboard computer. The memory 514 may store program instructions (e.g.,program instructions of the workspace management module 515) that areloadable and executable on the processor(s) 516, as well as datagenerated during the execution of these programs. Depending on theconfiguration and type of memory including the workspace managementmodule 515, the memory 514 may be volatile (such as random access memory(RAM)) and/or non-volatile (such as read-only memory (ROM), flashmemory, or other memory). The memory 514 may also include additionalremovable storage and/or non-removable storage including, but notlimited to, magnetic storage, optical discs, and/or tape storage. Thedisk drives and their associated computer-readable media may providenon-volatile storage of computer-readable instructions, data structures,program modules, and other data for the computing devices. In someimplementations, the memory 514 may include multiple different types ofmemory, such as static random access memory (SRAM), dynamic randomaccess memory (DRAM), or ROM. Turning to the contents of the memory 514in more detail, the memory 514 may include an operating system 520 andone or more application programs, modules or services for implementingthe features disclosed herein including at least the workspacemanagement module 515.

In some examples, the onboard computer may also include additionalstorage 522, which may include removable storage and/or non-removablestorage. The additional storage 522 may include, but is not limited to,magnetic storage, optical disks, and/or tape storage. The disk drivesand their associated computer-readable media may provide non-volatilestorage of computer-readable instructions, data structures, programmodules, and other data for the computing devices.

The memory 514 and the additional storage 522, both removable andnon-removable, are examples of computer-readable storage media. Forexample, computer-readable storage media may include volatile ornon-volatile, removable, or non-removable media implemented in anysuitable method or technology for storage of information such ascomputer-readable instructions, data structures, program modules, orother data. As used herein, modules may refer to programming modulesexecuted by computing systems (e.g., processors) that are part of theonboard computer 512. The modules of the onboard computer 512 mayinclude one or more components. The onboard computer 512 may alsoinclude input/output (I/O) device(s) 524 and/or ports, such as forenabling connection with a keyboard, a mouse, a pen, a voice inputdevice, a touch input device, a display, speakers, a printer, or otherI/O device. The I/O device(s) 524 may enable communication with theother systems of the MDU(s) 104 (e.g., navigation systems (notdepicted), drive controllers (not depicted), etc.). The sensor device(s)525 may include any suitable number of sensor devices (e.g., infraredsensors, thermal imaging sensors, digital cameras, video cameras, RFIDscanner and/or tags, or the like). The workspace management module 515may comprise code, that, when executed by the processor(s) 516 cause theMDU(s) 104 to collect and transmit sensor data at any suitable time, ata set frequency (e.g., every 10 seconds), periodically, in response toidentifying an unexpected object, or at any suitable time, or inresponse to any suitable stimulus. In some embodiments, the workspacemanagement module 515 may comprise code, that, when executed by theprocessor(s) 516 cause the MDU(s) 104 to collect and transmitnavigational information at any suitable time, at a set frequency (e.g.,every 10 seconds), periodically, upon reading a fiducial marker (e.g.,the fiducial markers 114 of FIG. 1), or at any suitable time, or inresponse to any suitable stimulus.

The onboard computer 512 may also include data store 526. The data store526 may include one or more databases, data structures, or the like forstoring and/or retaining information associated with the MDU(s) 104.

Turning now to the details of the computing device(s) 508. The computingdevice(s) 508 may be used by the user(s) 510 for interacting with theservice provider computer(s) 502. The computing device(s) 508 maytherefore include a memory, a processor, a user-interface, a web-serviceapplication, and any other suitable feature to enable communication withthe features of architecture of FIG. 5. The web service application maybe in the form of a web browser, an application programming interface(API), virtual computing instance, or other suitable application. Insome examples, when the service provider computer(s) 502 are part of, orshare an association with, an electronic marketplace, the computingdevice(s) 508 may be used by the user(s) 510 for procuring one or moreitems from the electronic marketplace. As discussed above, in someembodiments, the computing device(s) 508 may be operated by one or moreindividuals working with a workspace (e.g., the environment 100 of FIG.1).

The service provider computer(s) 502, perhaps arranged in a cluster ofservers or as a server farm, may host web service applications. Theseservers may be configured to host a website (or combination of websites)viewable via the computing device(s) 508. In at least one example, theservice provider computer(s) 502 may be configured to manage the MDU(s)104 as part of an inventory system (e.g., the environment 100 of FIG. 1)and/or the service provider computer(s) 502 may be configured to managea number of individuals within the inventory system via the computingdevice(s) 508. The service provider computer(s) 502 may include at leastone memory 532 and one or more processing units (or processor(s)) 534.The processor(s) 534 may be implemented as appropriate in hardware,computer-executable instructions, software, firmware, or combinationsthereof. Computer-executable instruction, software or firmwareimplementations of the processor(s) 534 may include computer-executableor machine-executable instructions written in any suitable programminglanguage to perform the various functions described.

The memory 532 may include more than one memory and may be distributedthroughout the service provider computer(s) 502. The memory 532 maystore program instructions (e.g., management module 533) that areloadable and executable on the processor(s) 534, as well as datagenerated during the execution of these programs. In some embodiments,obstacle management engine 103 may operate as part of the workspacemanagement module 533. It should be appreciated that the obstaclemanagement engine 103 may operate as a standalone module separate fromthe workspace management module 533. Depending on the configuration andtype of memory including the workspace management module 533, the memory532 may be volatile (such as random access memory (RAM)) and/ornon-volatile (such as read-only memory (ROM), flash memory, or othermemory). The service provider computer(s) 502 may also includeadditional removable storage and/or non-removable storage including, butnot limited to, magnetic storage, optical disks, and/or tape storage.The disk drives and their associated computer-readable media may providenon-volatile storage of computer-readable instructions, data structures,program modules, and other data for the computing devices. In someimplementations, the memory 532 may include multiple different types ofmemory, such as static random access memory (SRAM), dynamic randomaccess memory (DRAM), or ROM.

Turning to the contents of the memory 532 in more detail, the memory 532may include an operating system 538 and one or more applicationprograms, modules or services for implementing the features disclosedherein including at least the workspace management module 533. Theworkspace management module 533, in some examples, may functionsimilarly to the workspace management module 515 with respect todetermining tasks for the MDU(s) 104, determining a set of action toperform to execute the task, identifying paths for the MDU(s) 104 to beutilized for performance of their respective assigned tasks, etc. Forexample, when the MDU(s) 104 are in network communication with theservice provider computer(s) 502, the MDU(s) 104 may receive at leastsome instructions from the service provider computer(s) 502 (e.g., fromthe workspace management module 533). In some examples, the MDU(s) 104may execute any suitable portion of the workspace management module 533to operate independent of the service provider computer(s) 502.

In some examples, the service provider computer(s) 502 may also includeadditional storage 540, which may include removable storage and/ornon-removable storage. The additional storage 540 may include, but isnot limited to, magnetic storage, optical disks, and/or tape storage.The disk drives and their associated computer-readable media may providenon-volatile storage of computer-readable instructions, data structures,program modules, and other data for the computing devices.

The memory 532 and the additional storage 540, both removable andnon-removable, are examples of computer-readable storage media. Forexample, computer-readable storage media may include volatile ornon-volatile, removable, or non-removable media implemented in anysuitable method or technology for storage of information such ascomputer-readable instructions, data structures, program modules, orother data. As used herein, modules may refer to programming modulesexecuted by computing systems (e.g., processors) that are part of theservice provider computer(s) 502. The modules of the service providercomputer(s) 502 may include one or more components. The service providercomputer(s) 502 may also include input/output (I/O) device(s) 542 and/orports, such as for enabling connection with a keyboard, a mouse, a pen,a voice input device, a touch input device, a display, speakers, aprinter, or other I/O device.

In some examples, the service provider computer(s) 502 may include auser interface 544. The user interface 544 may be utilized by anoperator, or other authorized user to access portions of the serviceprovider computer(s) 502. In some examples, the user interface 544 mayinclude a graphical user interface, web-based applications, programmaticinterfaces such as application programming interfaces (APIs), or otheruser interface configurations. The service provider computer(s) 502 mayalso include data store 546. The data store 546 may include one or moredatabases, data structures, or the like for storing and/or retaininginformation associated with the service provider computer(s) 502. Insome examples, the service provider computer(s) 502 may store a largeramount of information in the data store 546 than the onboard computer512 is capable of storing in the data store 526. Thus, in some examples,at least a portion of the information from the databases in the datastore 546 (e.g., navigation data) may be provided to the databases ofthe data store 526, e.g., periodically, occasionally, in connection withan event, or otherwise.

In at least one embodiment, the workspace management module 515 and/orthe workspace management module 533 (hereinafter, the “managementmodules”) may provide the functionality of the workspace managementmodule 102 of FIG. 1. The obstacle management engine 103 may provide thefunctionality discussed above in connection with FIG. 1-4 as astandalone module or as part of the workspace management module 533and/or management module 515.

FIG. 6 illustrates in greater detail the components of an exampleworkspace management module 600 (e.g., the workspace management module102 of FIG. 1, the workspace management modules 515/533 of FIG. 5),including an obstacle management engine 602 (e.g., the obstaclemanagement engine 103 of FIGS. 1-5), that may be utilized in at leastone embodiment. As shown, the example embodiment includes a resourcescheduling module 604, a path planning module 606, a segment reservationmodule 608, an inventory module 610, a communication interface module612, and the obstacle management engine 602. As discussed above, theworkspace management module 600 may represent a single component,multiple components located at a central location within inventorysystem (e.g., the service provider computer(s) 502 of FIG. 5), ormultiple components distributed throughout inventory system. Forexample, workspace management module 600 may represent components of oneor more of MDU(s) 104 of FIG. 5 that are capable of communicatinginformation between the MDU(s) 104 and coordinating the movement of theMDU(s) 104 within a workspace (e.g., the workspace 106 of FIG. 1). Ingeneral, the workspace management module 600 may include any appropriatecombination of hardware and/or software suitable to provide thedescribed functionality. It should be appreciated that while theobstacle management engine 602 is depicted in FIG. 6 as part of theworkspace management module 600, the obstacle management engine 602 mayexecute as a process and/or module separate from, but in communicationwith, the workspace management module 600. By way of example, theobstacle management engine 602 may operate as a standalone moduleconfigured to communicate with any suitable combination of the workspacemanagement module 600, the navigational information data store 614, thesensor data store 616, the task assignment data store 618, and/or theobstacle information data store 620.

In at least one embodiment, the resource scheduling module 604 may beconfigured to process received inventory requests and generate one ormore assigned tasks to be completed by the components of the inventorysystem 500. The resource scheduling module 604 may also select one ormore appropriate components for completing the assigned tasks and maycommunicate, via the communication interface module 612, the assignedtasks to the relevant components. In some examples, the resourcescheduling module 604 may select the one or more appropriate components(e.g., MDUs) based on a location of the MDU (e.g., as determined byutilizing fiducial markers 114 of FIG. 1, by utilizing images/videos ofthe workspace 106 and image recognition techniques, by utilizing globalpositioning system devices of the MDU(s) 104, or by any suitablemethod). Additionally, the resource scheduling module 604 may also beresponsible for generating assigned tasks associated with variousmanagement operations, such as prompting MDU(s) 104 to rechargebatteries or have batteries replaced, instructing inactive MDU(s) 104 topark in a location outside the anticipated traffic flow or a locationnear the anticipated site of future tasks, and/or directing the MDU(s)104 selected for repair or maintenance to move towards a designatedmaintenance station. Additionally, the resource scheduling module 604may also be responsible for assigning tasks and/or updatingpreviously-assigned tasks in response to data (e.g., congestioninformation, supplemental information, etc.) provided and/or generatedby the obstacle management engine 602. In some embodiments, these taskassignments may be stored in task assignment data store 618.

In at least one embodiment, the path planning module 606 (e.g., anexample of the path planning module 406 of FIG. 4) may receive routerequests from the MDU(s) 104. These route requests may identify one ormore destinations associated with a task the requesting mobile driveunit is executing. In response to receiving a route request, the pathplanning module 606 may generate a path to one or more destinationsidentified in the route request. The path planning module 606 mayimplement any appropriate algorithms utilizing any appropriateparameters, factors, and/or considerations to determine the appropriatepath. In some embodiments, the path planning module 606 may beconfigured to receive obstacle information (or obtain obstacleinformation from the obstacle information data store 620). The pathplanning module 606 may utilize the obstacle information when generatingpaths such that the generated paths avoid traversing a location and/orarea associated with an obstacle. In some embodiments, the path planningmodule 606 may generate a path that traverses an area associated with anobstacle (e.g., congestion) as one of a number of possible paths for theMDU. However, a path selection process of the path planning module 606may be biased so as to prefer paths that do not traverse congestedlocations/areas (or locations/areas associated with other types ofobstacles) over paths that do. After generating (and selecting) anappropriate path, the path planning module 606 may transmit a responseidentifying the generated path to the requesting component (e.g., anMDU, the obstacle management engine 602). In some embodiments, the pathplanning module 606 may communicate the generated path using thecommunication interface module 612. In some embodiments, the pathplanning module 606 may store the planned path in the task assignmentdata store 618 as part of the task assignment or in a separate recordassociated with the task assignment. In some embodiments, the plannedpath associated with a task may be stored in a separate data store (notdepicted) which is accessible to any suitable component of the workspacemanagement module 600.

In at least one embodiment, the segment reservation module 608 mayreceive reservation requests from the MDU(s) 104 attempting to movealong paths generated by the path planning module 606. These reservationrequests may indicate a request for the use of a particular portion ofthe workspace 106 (referred to herein as a “segment”) to allow therequesting mobile drive unit to avoid collisions with other MDU(s) 104while moving across the reserved segment. In response to receivedreservation requests, segment reservation module 608 may transmit areservation response granting or denying the reservation request to therequesting mobile drive unit using the communication interface module612. In some embodiments, the reservation requests may constitutenavigational information and may be stored within the navigationalinformation data store 614.

In at least one embodiment, the inventory module 610 may maintaininformation about the location and number of inventory items in theinventory system 500. Information can be maintained about the inventoryitems in a particular receptacle (e.g., a receptacle 112 of FIG. 1), andthe maintained information can include the location of those inventoryitems within the receptacle (e.g., within a sub-area of a storagecontainer, within a bin, tote, etc.). The inventory module 610 can alsocommunicate with the MDU(s) 104, utilizing task assignments to maintain,replenish or move inventory items within the inventory system 500.

In at least one embodiment, the communication interface module 612 mayfacilitate communication between workspace management module 600 andother components of inventory system 500, including reservationresponses, reservation requests, path requests, path responses, and taskassignments. These reservation responses, reservation requests, pathrequests, path responses, and task assignments may representcommunication of any form appropriate based on the capabilities ofworkspace management module 600 and may include any suitableinformation. Depending on the configuration of workspace managementmodule 600, communication interface module 612 may be responsible forfacilitating either or both of wired and wireless communication betweenworkspace management module 600 and the various components of inventorysystem 500. In particular embodiments, workspace management module 600may communicate using communication protocols such as 802.11, Bluetooth,or Infrared Data Association (IrDA) standards. Furthermore, workspacemanagement module 600 may, in particular embodiments, represent aportion of mobile drive unit or another component of inventory system500. In such embodiments, communication interface module 612 mayfacilitate communication between workspace management module 600 andother parts of the same system component.

Any suitable component of the workspace management module 600 may beconfigured to receive sensor data from one or more MDUs and store suchdata within the sensor data store 616. Similarly, any suitable componentof the workspace management module 600 may be configured to receivenavigational information at any suitable time from one or more MDUs andstore such data within the navigational information data store 614.

In some embodiments, the obstacle management engine 602 may beconfigured obtain navigational information (e.g., from the navigationalinformation data store 614). The navigational information may correspondto one or more components (e.g., MDUs, user computing devices, etc.) ofthe workspace and may have been initially provided to any suitablemodule of the workspace management module 600 and stored in thenavigational information data store 614. Alternatively, the obstaclemanagement engine 602 may request navigational information for thecomponents (e.g., MDUs, user computing devices, robotic arms, etc.) ofthe workspace from any suitable module of the workspace managementmodule 600 and/or from the components directly. The obstacle managementengine 602 may utilize the navigational information to identify acurrent location (and/or other attributes such as current speed, currentstate, etc.) for each of the components within the workspace.

In some embodiments, the obstacle management engine 602 may beconfigured obtain sensor data (e.g., from the sensor data store 616).The sensor may correspond to one or more components (e.g., sensors ofone or more MDUs, standalone sensors, sensors of a user computing deviceand/or robotic arm, etc.) and may have been initially provided to anysuitable module of the workspace management module 600 and stored in thesensor data store 616. Alternatively, the obstacle management engine 602may request sensor data from the components of the workspace (e.g.,MDUs, user computing devices, robotic arms, etc.) and/or from anysuitable module of the workspace management module 600.

In some embodiments, the obstacle management engine 602 may beconfigured to obtain restricted space data from the obstacle informationdata store 620. The restricted space data may be user defined and/orpredefined to indicate one or more locations/areas of the workspace thatare restricted, that is, locations/areas that are to be avoided by theMDUs. In some embodiments, the restricted space data may indicate alocation/area is restricted based at least in part on a specifiedday/time, or in some embodiments, the restricted space may be persistent(e.g., the location/area is restricted regardless of the day and/ortime).

The obstacle management engine 602 may be configured to detect one ormore obstacles from any suitable combination of the navigationalinformation and/or the sensor data and/or the restricted space data. Byway of example, the obstacle management engine 602 may be configured todetermine that an instance of sensor data indicates an obstacle (e.g., acondition that is not supposed to be occurring with the workspace). Insome embodiments, the obstacle management engine 602 may be configuredto determine a location associated with the sensor collector (e.g., anMDU, a standalone sensor, etc.). Utilizing the sensor data and/or thelocation associated with the sensor collector, the obstacle managementengine 602 may identify a location associated with the obstacle.Regardless of the particular data utilized to detect the obstacle, theobstacle management engine 602 may generate obstacle information (e.g.,indicating a type of obstacle, the location and/or area of the obstacle,or any suitable information describing any suitable aspect of theobstacle) for each detected/determined obstacle and may store thisobstacle information in obstacle information data store 620. In someembodiments, the obstacle management engine 602 may provide the obstacleinformation to any suitable component of the workspace management module600 (e.g., the path planning module 606).

In some embodiments, the obstacle may be detected based at least in parton navigational information provided by the MDUs of the system. In someembodiments, the obstacle management engine 602 may be configured togenerate a grid of volumes corresponding to various sub portions of theworkspace. These volumes may include a set of vertical volumes and/or aset of horizontal volumes. Each volume may overlap one or more othervolumes and the grid of volumes may be generated to cover the entireworkspace. The obstacle management engine 602 may perform operations togenerate density values for each of the volumes of the grid, utilizingthe navigational information indicating locations of each MDU. A currentdensity value for each volume may be generated to indicate a number ofMDUs currently within an area associated with the given volume. In someembodiments, a set of one or more historic density values may begenerated for each volume corresponding to a number of historic timeperiods (e.g., 0-20 seconds of the last minute, 20-40 seconds of thelast minute, 40-60 of the last minute, etc.).

In some embodiments, the obstacle management engine 602 may beconfigured to generate a set of one or more future density values (foreach volume) corresponding to a number of future time periods (e.g.,0-10 seconds in the future, 10-20 seconds in the future, etc.). Thefuture density values may be generated by the obstacle management engine602 based at least in part on planned path data associated with anysuitable number of the MDUs in the workspace 204. The obstaclemanagement engine 602 may be configured to execute a protocol setutilizing the current density value, one or more historic densityvalues, and/or one or more future density values associated with a givenvolume to determine when a volume has become (or will become) congested.When an area of current and/or future congestion is identified, theobstacle management engine 602 may be configured to generate obstacleinformation that describes any suitable aspect of the congestion (e.g.,a location/area of the congestion, etc.) and store the obstacleinformation within the obstacle information data store 620 (e.g., anexample of the obstacle information data store 404 of FIG. 4).

The obstacle management engine 602 may be configured to update pathplanning operations for the workspace utilizing the obstacleinformation. In some embodiments, storing the obstacle information inthe obstacle information data store 404 may cause path planningoperations (e.g., performed by the path planning module 606) to utilizethe obstacle information when determining new paths for task execution.In some embodiments, the obstacle management engine 602 may beconfigured to provide an indication of the existence of the obstacles,or the obstacle information itself, directly to the path planning module606 to stimulate utilization of the obstacle information for pathplanning purposes.

The obstacle management engine 602 may be configured to identify one ormore tasks affected by the detected obstacle. As a non-limiting example,the obstacle management engine 602 may obtain planned path data for thetask assigned to each MDU in the workspace (e.g., from the taskassignment data store 618). The planned path data for each task may beutilized, along with the location/area of the obstacle (e.g., a portionof the obstacle information), to identify that a particular task isaffected by the obstacle.

In some embodiments, the obstacle management engine 602 may beconfigured to determine that one or more of the tasks of the MDUs are tobe reassigned and/or cancelled in light of the detected obstacle. Theobstacle management engine 602 may determine whether or not an obstacleis detected at a source location or destination location associated withthe task, or at a current location of the MDU. If the obstacle isdetected at one of these locations, the obstacle management engine 602may determine, based at least in part on any suitable attributeassociated with the obstacle (e.g., type, size, shape, duration ofexistence, etc.) that the task is to be reassigned or cancelled. Forexample, a fallen object located at a destination location of theplanned path may cause the task to be cancelled while congestionoccurring at the destination location may not. In some embodiments, theobstacle management engine 602 may perform any suitable operations tocause these tasks to be reassigned and/or cancelled.

In some embodiments, the obstacle management engine 602 may beconfigured to transmit new path requests to the path planning module 606to request a new path(s) for tasks associated with one or more MDUs. Byway of example, the obstacle management engine 602 may submit a new pathrequest to the path planning module 606 for each task that has beendetermined to be affected by the detected obstacle. In some embodiments,the obstacle management engine 602 may not submit a new path request fortasks that have already been reassigned or cancelled. In response to anew path request, the path planning module 606 may be configured toattempt generation of a new path for the corresponding MDU. As part ofgenerating a new path, the path planning module 606 may obtain obstacleinformation from the obstacle management engine 602 and/or the obstacleinformation data store 620. The path planning module 606 may generateresponse data including a new path generated and/or an indication thatthe request was denied (or that a new path could not be generated inlight of the obstacles within the workspace). Response data (e.g.,indicating a new path for the MDU, or indicating that a new path couldnot be determined, etc.) may be provided to the obstacle managementengine 602 for further processing.

In some embodiments, the obstacle management engine 602 may beconfigured to determine whether the originally planned path (the currentpath) of the MDU is “infeasible,” that is, a delay (or other cost) wouldbe incurred by executing the originally planned path exceeds apredetermined infeasibility threshold. A planned path may be determinedto be “infeasible” based at least in part on determining that a delay intask completion has exceeded a threshold infeasibility amount due to thedetected obstacle. In some embodiments, the obstacle management engine602 may be configured to generate a metric (e.g., an estimatedcompletion time) that identifies a time of completion for the taskshould the planned path be utilized for task execution in light of theobstacle detected. In some embodiments, a task completion time that wasdetermined before the obstacle was detected (herein referred to as the“original task completion time”) may be compared to the estimated taskcompletion time that is calculated based at least in part on theobstacle detected (herein referred to as the “obstacle-based taskcompletion time”). If the obstacle-based task completion time exceedsthe original task completion time by at least the predeterminedinfeasibility threshold, then executing the task utilizing the plannedpath may be considered “infeasible.”

In situations in which the planned path has been determined to beinfeasible, and the response data indicates a denial of the request(e.g., a new path was unavailable, etc.), the obstacle management engine602 may be configured to transmit any suitable data to any suitablemodule of the workspace management module 600 (e.g., the resourcescheduling module 604) in order to cause the task assigned to the MDU tobe reassigned to a different MDU or cancelled altogether.

As another example, if a new path was provided in the response data, theobstacle management engine 602 may be configured to generate a metricfor the new path that identifies a time of completion for the taskshould the new path be utilized for task execution (herein referred toas a “new path completion time”). In some embodiments, if a comparisonof the new path completion time to the original task completion timeexceeds the infeasibility threshold, the obstacle management engine 602may transmit any suitable data to any suitable module of the workspacemanagement module 600 (e.g., the resource scheduling module 604) inorder to cause the task assigned to the MDU to be reassigned to adifferent MDU or cancelled altogether. Thus, if the planned path isdetermined to be infeasible and the new path is also determined to beinfeasible, the task may be reassigned or cancelled.

In some embodiments, if the planned path is determined to be infeasible,but the new path is not infeasible (e.g., the new path completion timeis less than the original completion time of the planned path, or atleast does not exceed the original completion time by over theinfeasibility threshold, etc.), the obstacle management engine 602 mayassociated the task with an “Alternate_Feasible_Path” label. In someembodiments, the obstacle management engine 602, through thisassociation or otherwise, may cause the MDU assigned to the task toexecute the task utilizing the new path. The obstacle management engine602 may perform any suitable operations to cause the MDU to commenceexecution of the task utilizing the new path such as transmitting thetask, the label, and/or the new path to the MDU and/or to the workspacemanagement module.

In some embodiments, the obstacle management engine 602 may determinethat, although the planned path is not infeasible, the new path mayresult in a completion time that is less than the obstacle-basedcompletion time and/or original completion time of the planned path byat least a predetermined cost threshold amount. Accordingly, theobstacle management engine 602 may determine that the new path is acheaper alternative to the planned path. In some embodiments, theobstacle management engine 602 may store an association of the new pathand the MDU with a classification label indicating that a cheaper pathexists (e.g., “Cheaper_Path_Available”). In some embodiments, theobstacle management engine may update a corresponding task (e.g., a taskassignment) to indicate the classification label and/or the new path.Any suitable combination of the task assignment, classification label,and/or new path may be provided to the MDU and/or workspace managementsystem. The MDU and/or the workspace management system may perform anysuitable operations to determine whether or not to cause the MDU toexecute the task utilizing the new path.

In some embodiments, if the planned path is not infeasible and the newpath is not cheaper than the planned path by at least the cost thresholdamount, the obstacle management engine 103 may be configured to ignorethe existence of the new path and the MDU may continue executing thetask utilizing the planned path.

It should be appreciated that completion times are utilized as anexample only. It is contemplated that the obstacle management engine 602may perform a comparison between the planned path and the new pathutilizing completion times and/or any suitable combination ofparameters/metrics to identify which path should be utilized for taskexecution. Example parameters may include a priority of the task, adistance between the current location of the MDU and the destinationlocation for the task, whether or not the task corresponds to conveyanceof an item, a priority associated with the item (e.g., expeditedshipping of the item), any suitable parameter associated with the task,a determination that one or more other planned paths would need to bealtered in the workspace should new path be utilized, a determinationthat executing the new path may create a new obstacle (e.g., based onfuture congestion), and the like.

In some embodiments, the obstacle management engine 602 may beconfigured to perform one or more remedial actions. For example, theobstacle management engine 602 may provide a notification (e.g., anemail, a text message, an audible alert, a push notification, etc.) toone or more network pages and/or user computing devices to indicate theexistence of the obstacle. As another example of a remedial action, theobstacle management engine 602 may transmit the new path and/or theclassification label to an MDU to cause the planned path of the MDU tobe altered. As another example, the obstacle management engine 602 maytransmit at least the classification label or another indicatorcorresponding to the classification label that, upon receipt, may causean MDU to request a new path from the workspace management module 102(e.g., from the path planning module 606). As yet another example, theobstacle management engine 602 may store the classification label, newpath, and/or any suitable obstacle information within the obstacleinformation data store 620 to make the obstacle information accessibleto one or more modules of the workspace management module 102. As yetanother example, the obstacle management engine 602 may request that atask be reassigned and/or cancelled. In some embodiments, storing theobstacle information within the obstacle information data store 620and/or providing the obstacle information directly to the path planningmodule 606 may cause the path planning module 606 (or any suitablemodule of the workspace management module 102) to perform, at anysuitable time, one or more operations. For example, the path planningmodule 606 may utilize obstacle information provided/stored by theobstacle management engine 602 (e.g., obstacle information of theobstacle information data store 620) when generating paths for MDUswithin the workspace. In some embodiments, the paths may be generated soas to avoid any known obstacles.

In general, the resource scheduling module 604, the path planning module606, the segment reservation module 608, the inventory module 610, thecommunication interface module 612, and the obstacle management engine602, may each represent any appropriate hardware and/or softwaresuitable to provide the described functionality. In addition, as notedabove, workspace management module 600 may, in particular embodiments,represent multiple different discrete components and any or all of theresource scheduling module 604, the path planning module 606, thesegment reservation module 608, the inventory module 610, thecommunication interface module 612, and the obstacle management engine602 may represent components physically separate from the remainingelements of workspace management module 600. Moreover, any two or moreof the resource scheduling module 604, the path planning module 606, thesegment reservation module 608, the inventory module 610, thecommunication interface module 612, and/or the obstacle managementengine 602 may share common components.

FIG. 7 is a flowchart illustrating an example method 700 for performingone or more remedial actions in response to obstacle detection within aworkspace, in accordance with at least one embodiment. The method may beperformed by a system (e.g., the inventory system 500 of FIG. 5)comprising a plurality of mobile drive units located within a facility(e.g., a sortation facility, a storage facility, etc.) and individuallyconfigured to move items within the facility, one or more data networks,a resource scheduling module (e.g., the resource scheduling module 604of FIG. 6), a path planning module (e.g., the path planning module 606of FIG. 6), an obstacle management engine (e.g., the obstacle managementengine 103 and/or 602 of FIGS. 1-6), one or more processors, and one ormore memories storing computer-readable instructions that, uponexecution by the one or more processors, cause the inventory system toat least to perform the operations of method 700. It should beappreciated that the system may alternatively include a plurality ofuser computing devices and/or robotic devices located within thefacility and that the method 700 may similarly be applied in these usecases.

The method may begin at block 702, where first obstacle informationassociated with a first obstacle located within the sortation facilityis obtained. The first obstacle information may be obtained (e.g.,generated) by the obstacle management engine 602 based at least in parton any suitable combination of sensor data and/or navigationalinformation provided by any suitable number of components of the system(e.g., MDUs, standalone sensors, sensors of user computing devices, usercomputing devices, robotic arms, sensors of robotic arms, etc.).

At 704, a planned path for executing a task within the sortationfacility may be identified (e.g., by the obstacle management engine 602utilizing the planned path data of the planned path data store 618 ofFIG. 6). In some embodiments, the task may be currently assigned to afirst mobile drive unit of the plurality of mobile drive units. Theplanned path may be identified based at least in part on the firstobstacle information. That is, the planned path may be identified basedat least in part on determining that a location of the obstacle, asprovided in the first obstacle information, overlaps/intersects someportion of the planned path (e.g., a portion of the planned path thathas not yet been executed).

At 706, a request may be sent to the path planning module (e.g., pathplanning module 606 of FIG. 6) for generating a new path for the firstmobile drive unit to execute the task. In some embodiments, thegeneration of the new path may be based at least in part on the firstobstacle information. That is, the path planning module 606 may utilizethe first obstacle information (and potentially obstacle information ofall known obstacles) to ensure that the new path does not include alocation associated with the obstacle.

At 708, if a denial to the request is received, data associated with thetask and the first mobile drive unit may be transmitted (e.g., by theobstacle management engine 602), to the resource scheduling module(e.g., the resource scheduling module 604), to cause the resourcescheduling module to reassign the task to a different mobile drive unitof the plurality of mobile drive units.

At 710, if the new path is/has been generated, a remedial action may beperformed based at least in part on the new path. By way of example, theobstacle management engine 602 may generate a metric for the new paththat identifies a time of completion for the task should the new path beutilized for task execution (herein referred to as a “new pathcompletion time”). In some embodiments, if a comparison of the new pathcompletion time to the original task completion time exceeds theinfeasibility threshold, the obstacle management engine may transmit anysuitable data to any suitable module of the workspace management modulein order to cause the task assigned to the MDU to be reassigned to adifferent MDU or cancelled altogether. Thus, if the planned path isdetermined to be infeasible and the new path is also determined to beinfeasible, the task may be reassigned or cancelled. In someembodiments, the method 700 may end at 710 or the method may continue to712.

As another example, if the planned path is determined to be infeasible,but the new path is not infeasible (e.g., the new path completion timeis less than the original completion time of the planned path, or atleast does not exceed the original completion time by over theinfeasibility threshold, etc.), the obstacle management engine mayassociated the task with an “Alternate_Feasible_Path” label. In someembodiments, the obstacle management engine, through this association orotherwise, may cause the MDU assigned to the task to execute the taskutilizing the new path. The obstacle management engine may perform anysuitable operations to cause the MDU to commence execution of the taskutilizing the new path such as transmitting the task, the label, and/orthe new path to the MDU and/or to the workspace management module.

As yet another example, the obstacle management engine may determinethat, although the planned path is not infeasible, the new path mayresult in a completion time that is less than the obstacle-basedcompletion time and/or original completion time of the planned path byat least a predetermined cost threshold amount. Accordingly, theobstacle management engine may determine that the new path is a cheaperalternative to the planned path. In some embodiments, the obstaclemanagement engine may store an association of the new path and the MDUwith a classification label indicating that a cheaper path exists (e.g.,“Cheaper_Path_Available”). In some embodiments, the obstacle managementengine may update a corresponding task (e.g., a task assignment) toindicate the classification label and/or the new path. Any suitablecombination of the task assignment, classification label, and/or newpath may be provided to the MDU and/or workspace management system. TheMDU and/or the workspace management system may perform any suitableoperations to determine whether or not to cause the MDU to execute thetask utilizing the new path.

As yet another example of a remedial action, the obstacle managementengine may notify one or more users of the existence of the detectedobstacle. This notification may be in any suitable electronic form(e.g., email, text message, display via a network page hosted by theobstacle management engine, etc.).

In some embodiments, if the planned path is not infeasible and the newpath is not cheaper than the planned path by at least the cost thresholdamount, the obstacle management engine may ignore the new path and theMDU may continue executing the task utilizing the planned path.

At 712, subsequent obstacle information associated with a plurality ofobstacles located within the sortation facility may be obtained (e.g.,by the obstacle management engine 602). For example, the obstaclemanagement engine 602 may generate obstacle information for eachobstacle subsequently detected (e.g., utilizing subsequent sensor dataand/or subsequent navigational information and/or restricted spacedata).

At 714, second obstacle information by at least excluding the firstobstacle information from the subsequent obstacle information. Saidanother way, the obstacle management engine 602 may exclude the firstobstacle information from being reprocessed by the system after one ormore remedial actions have been performed by generating obstacleinformation only for newly detected obstacles.

At 716, operations may be performed (e.g., by the obstacle managementengine 602 and/or the path planning module 606) to generate a new pathfor a second mobile drive unit based at least in part on the secondobstacle information.

FIG. 8 is a flowchart illustrating another example method 800 forperforming one or more remedial actions in response to obstacledetection within a workspace, in accordance with at least oneembodiment. The method 800 may be performed by the obstacle managementengine 602 of FIG. 6, an example of the obstacle management engine 103of FIGS. 1-5.

The method may begin at block 802, where obstacle information associatedwith an obstacle detected within a workspace may be obtained by theobstacle management engine 602. In some embodiments, the obstacleinformation may be generated by the obstacle management engine 602 basedat least in part on any suitable sensor data and/or navigationalinformation accessible to the obstacle management engine 602.

At 804, a planned path for executing a task within the workspace may beidentified by the obstacle management engine (e.g., the obstaclemanagement engine 103 and/or 602 of FIG. 1-6). In some embodiments, thetask may be assigned to a mobile drive unit. According to someembodiments, the task and/or the planned path may be identified based atleast in part on obstacle information (e.g., obstacle information havingbeen previously received and stored within the obstacle information datastore 620, the obstacle information obtained at 802, etc.).

At 806, a new path for the mobile drive unit to execute the task may beobtained by the obstacle management engine 602. In some embodiments, thenew path may be generated (e.g., by the path planning module 606 of FIG.6) based at least in part on the obstacle information.

At 808, a remedial action may be performed by the obstacle managementengine 602 to alter execution of the task by the mobile drive unit basedat least in part on the new path. By way of example, the obstaclemanagement engine 602 may transmit the new path to the MDU to cause theMDU to cause the MDU to begin execution of the new path. In someembodiments, transmitting the new path to the MDU may cause the MDU toexchange information with any suitable number of modules of a workspacemanagement module (e.g., the workspace management module 600 of FIG. 6)to cause the MDU to execute the new path.

At 810, operations may be performed by the obstacle management engine602 to cause another path corresponding to a different mobile drive unitto be altered or generated based at least in part on the obstacleinformation and the historical obstacle information. By way of example,the obstacle management engine 602 may store obstacle information in adata store accessible to other modules of the workspace managementmodule 102. This stored information may be utilized by components of theworkspace management module 102 to generate paths for the components ofthe system that cause the components (e.g., the MDUs) to avoid theobstacles.

FIG. 9 is a flowchart illustrating an example method 900 for alteringtask execution in response to obstacle detection, in accordance with atleast one embodiment. A computer-readable storage medium may comprisecomputer-readable instructions that, upon execution by one or moreprocessors, cause the one or more processors to perform the operationsof method 900. The operations of the method 900 may be performed by theobstacle management engine 602 of FIG. 6, an example of the obstaclemanagement engine 103 of FIGS. 1-5.

The method may begin at block 902, where obstacle information associatedwith an obstacle detected within a workspace may be obtained (e.g., fromthe obstacle information data store 620 of FIG. 6). In some embodiments,the obstacle information may be obtained by the obstacle managementengine 602 by generating the obstacle information based at least in parton any suitable combination of sensor data and/or navigationalinformation collected by any suitable combination of one or more MDUsand/or one or more sensors located within a workspace.

At 904, a planned path for executing a task within the workspace may beidentified. In some embodiments, the task may be assigned to a mobiledrive unit operating within the workspace. In some embodiments, the taskand/or the planned path may be identified based at least in part on theobstacle information. That is, the planned path may be identified, forexample, based at least in part on determining that a location/areaindicated in the obstacle information and associated with the obstacleoverlaps/intersects at least a portion of the planned path.

At 906, a new path for the mobile drive unit to execute the task may beobtained. In some embodiments, the new path may be obtained (and/orgenerated) based at least in part on the obstacle information.

At 908, task execution of the mobile drive unit may be altered based atleast in part on the planned path and the new path. In some embodiments,the obstacle management engine 602 may generate any suitable metrics ofthe planned path and any suitable metrics of the new path. The obstaclemanagement engine 602 may utilize the generated metrics to compare theplanned path to the new path. In some embodiments, if the new path isdetermined to be more advantageous (e.g., based on the comparison), thetask execution of the mobile drive unit may be altered to utilize thenew path.

At 910, an additional task execution of at least one additional mobiledrive unit within the workspace may be altered based at least in part onthe obstacle information. That is, any suitable number of tasks and/orpaths of any suitable number of mobile drive units may be altered basedat least in part on the obstacle information.

The specification and drawings are, accordingly, to be regarded in anillustrative rather than a restrictive sense. It will, however, beevident that various modifications and changes may be made thereuntowithout departing from the broader spirit and scope of the disclosure asset forth in the claims.

Other variations are within the spirit of the present disclosure. Thus,while the disclosed techniques are susceptible to various modificationsand alternative constructions, certain illustrated embodiments thereofare shown in the drawings and have been described above in detail. Itshould be understood, however, that there is no intention to limit theinvention to the specific form or forms disclosed, but on the contrary,the intention is to cover all modifications, alternative constructionsand equivalents falling within the spirit and scope of the invention, asdefined in the appended claims.

The use of the terms “a” and “an” and “the” and similar referents in thecontext of describing the disclosed embodiments (especially in thecontext of the following claims) are to be construed to cover both thesingular and the plural, unless otherwise indicated herein or clearlycontradicted by context. The terms “comprising,” “having,” “including,”and “containing” are to be construed as open-ended terms (i.e., meaning“including, but not limited to,”) unless otherwise noted. The term“connected” is to be construed as partly or wholly contained within,attached to, or joined together, even if there is something intervening.Recitation of ranges of values herein are merely intended to serve as ashorthand method of referring individually to each separate valuefalling within the range, unless otherwise indicated herein and eachseparate value is incorporated into the specification as if it wereindividually recited herein. All methods described herein can beperformed in any suitable order unless otherwise indicated herein orotherwise clearly contradicted by context. The use of any and allexamples, or exemplary language (e.g., “such as”) provided herein, isintended merely to better illuminate embodiments of the invention anddoes not pose a limitation on the scope of the invention unlessotherwise claimed. No language in the specification should be construedas indicating any non-claimed element as essential to the practice ofthe invention.

Disjunctive language such as the phrase “at least one of X, Y, or Z,”unless specifically stated otherwise, is intended to be understoodwithin the context as used in general to present that an item, term,etc., may be either X, Y, or Z, or any combination thereof (e.g., X, Y,and/or Z). Thus, such disjunctive language is not generally intended to,and should not, imply that certain embodiments require at least one ofX, at least one of Y, or at least one of Z to each be present.

Preferred embodiments of this disclosure are described herein, includingthe best mode known to the inventors for carrying out the invention.Variations of those preferred embodiments may become apparent to thoseof ordinary skill in the art upon reading the foregoing description. Theinventors expect skilled artisans to employ such variations asappropriate and the inventors intend for the invention to be practicedotherwise than as specifically described herein. Accordingly, thisinvention includes all modifications and equivalents of the subjectmatter recited in the claims appended hereto as permitted by applicablelaw. Moreover, any combination of the above-described elements in allpossible variations thereof is encompassed by the invention unlessotherwise indicated herein or otherwise clearly contradicted by context.

All references, including publications, patent applications and patents,cited herein are hereby incorporated by reference to the same extent asif each reference were individually and specifically indicated to beincorporated by reference and were set forth in its entirety herein.

What is claimed is:
 1. A sortation system, comprising: a plurality ofmobile drive units located within a sortation facility and individuallyconfigured to move items within the sortation facility; one or more datanetworks; a resource scheduling module separate from the plurality ofmobile drive units and configured to assign the plurality of mobiledrive units a plurality of tasks to be executed within the sortationfacility; a path planning module separate from the plurality of mobiledrive units and configured to calculate corresponding paths forexecution of the plurality of tasks; and an obstacle management engineseparate from the plurality of mobile drive units, the obstaclemanagement engine comprising: one or more processors; and one or morememories storing computer-readable instructions that, upon execution bythe one or more processors, cause the obstacle management engine to atleast: obtain, from one or more mobile drive units of the plurality ofmobile drive units, first obstacle information associated with a firstobstacle located within the sortation facility; identify a planned pathfor executing a task within the sortation facility, the task currentlybeing assigned to a first mobile drive unit of the plurality of mobiledrive units, the planned path being identified based at least in part onthe first obstacle information, the first mobile drive unit beingdifferent from the one or more mobile drive units from which the firstobstacle information was obtained; send a request, to the path planningmodule, for generating a new path for the first mobile drive unit toexecute the task, the generation of the new path being based at least inpart on the first obstacle information; if a denial to the request isreceived, transmit, to the resource scheduling module, data associatedwith the task and the first mobile drive unit thereby causing theresource scheduling module to cancel the task or reassign the task to adifferent mobile drive unit of the plurality of mobile drive units; andif the new path is generated, perform one or more remedial actions basedat least in part on the new path.
 2. The sortation system of claim 1,wherein performing the one or more remedial actions causes the obstaclemanagement engine to: generate a first estimated completion timeassociated with the planned path; generate a second estimated completiontime associated with the new path; and when the second estimatedcompletion time is less than the first estimated completion time by atleast a threshold amount, transmit, over the one or more data networksto the first mobile drive unit, path data, the first estimatedcompletion time, and the second estimated completion time therebycausing the first mobile drive unit to alter execution of the task. 3.The sortation system of claim 2, wherein performing the one or moreremedial actions causes the obstacle management engine to: generate aclassification label identifying the new path as an alternative feasiblepath or a cheaper path; and transmitting, with the path data, theclassification label to the first mobile drive unit thereby causing thefirst mobile drive unit to determine whether to alter execution of thetask based at least in part on the classification label.
 4. Thesortation system of claim 3, wherein the classification label isdetermined based at least in part on a comparison between the firstestimated completion time and the second estimated completion time.
 5. Acomputer-implemented method, comprising: obtaining, by an obstaclemanagement engine, obstacle information associated with an obstacledetected within a workspace, the obstacle information being generated bya first mobile drive unit of a plurality of mobile drive units, theobstacle management engine being different from the plurality of mobiledrive units; identifying, by the obstacle management engine, a plannedpath for executing a task within the workspace, the task being assignedto a second mobile drive unit, the planned path being identified basedat least in part on the obstacle information; obtaining, by the obstaclemanagement engine, a new path for the second mobile drive unit toexecute the task, the new path being generated based at least in part onthe obstacle information generated by the first mobile drive unit;performing, by the obstacle management engine, one or more remedialactions to alter execution of the task by the second mobile drive unitbased at least in part on the new path; and performing, by the obstaclemanagement engine, operations to cause another path corresponding to adifferent mobile drive unit to be generated based at least in part onthe obstacle information.
 6. The computer-implemented method of claim 5,wherein the obstacle comprises at least one of: a physical objectlocated within the workspace, a restricted space, or an area identifiedas being congested currently or at a future time.
 7. Thecomputer-implemented method of claim 5, further comprising: determining,by the obstacle management engine, that the obstacle informationindicates that the obstacle is located at a source location associatedwith the task or a destination location associated with the task,wherein determining that the obstacle information indicates that theobstacle is located at the source location or the destination locationcauses the obstacle management engine to forgo a request to generate thenew path; and transmitting, by the obstacle management engine to aresource scheduling module, data that causes the resource schedulingmodule to reassign the task to another mobile drive unit, wherein thedata is transmitted based at least in part on determining that theobstacle is located at the source location or the destination location.8. The computer-implemented method of claim 7, further comprising:determining an attribute associated with the obstacle based at least inpart on the obstacle information, wherein transmitting the data isfurther based at least in part on the attribute associated with theobstacle.
 9. The computer-implemented method of claim 5, whereinperforming the one or more remedial actions further comprises:generating, by the obstacle management engine, a first metric associatedwith the planned path; generating, by the obstacle management engine, asecond metric associated with the new path; associating, by the obstaclemanagement engine, the new path with a classification label based atleast in part on a comparison of the first metric and the second metric;and transmitting, by the obstacle management engine, at least theclassification label and the new path to cause the second mobile driveunit to alter execution of the task.
 10. The computer-implemented methodof claim 9, wherein the new path is associated with the classificationlabel based at least in part on a comparison of the first metric and thesecond metric indicating that the second metric is less than the firstmetric by at least a threshold amount.
 11. The computer-implementedmethod of claim 5, further comprising: generating, by the obstaclemanagement engine, subsequent obstacle information associated with asubsequent obstacle detected within the workspace, the subsequentobstacle information being generated by at least excluding the obstacleinformation associated with the obstacle; and performing, by theobstacle management engine, a subsequent remedial action to alterexecution of a corresponding task of another mobile drive unit of theplurality of mobile drive units, the execution being altered based atleast in part on the subsequent obstacle information.
 12. Thecomputer-implemented method of claim 11, wherein generating thesubsequent obstacle information by at least excluding the obstacleinformation associated with the obstacle reduces a computational burdenof the obstacle management engine.
 13. The computer-implemented methodof claim 5, wherein the planned path is identified based at least inpart on determining that the planned path overlaps an area associatedwith the obstacle, the area being indicated by the obstacle information.14. A non-transitory computer-readable storage medium comprisingcomputer-readable instructions that, upon execution by one or moreprocessors of an obstacle management system, cause the obstaclemanagement system to perform operations comprising: obtaining, by anobstacle management engine, obstacle information associated with anobstacle detected within a workspace, the obstacle information beinggenerated by a first mobile drive unit of a plurality of mobile driveunits, the obstacle management engine being different from the pluralityof mobile drive units; identifying a planned path for executing a taskwithin the workspace, the task being assigned to a second mobile driveunit of the plurality of mobile drive units, the planned path beingidentified based at least in part on the obstacle information; obtaininga new path for the second mobile drive unit to execute the task, the newpath being obtained based at least in part on the obstacle informationgenerated by the first mobile drive unit; altering task execution of thesecond mobile drive unit based at least in part on the planned path andthe new path; and altering additional task execution of at least oneadditional mobile drive unit of the plurality of mobile drive unitsbased at least in part on the obstacle information generated by thefirst mobile drive unit.
 15. The non-transitory computer-readablestorage medium of claim 14, wherein altering the task execution of thesecond mobile drive unit comprises causing the task to be reassigned toanother mobile drive unit, causing the task to be cancelled, or causingthe second mobile drive unit to begin executing the new path.
 16. Thenon-transitory computer-readable storage medium of claim 15, wherein theoperations further comprise: generating a first metric associated withthe planned path and a second metric associated with the new path,wherein altering the task execution of the second mobile drive unit maybe further based at least in part on determining that the first metricexceeds the second metric by at least a threshold amount.
 17. Thenon-transitory computer-readable storage medium of claim 14, wherein theoperations further comprise: detecting that the obstacle is located atan obstacle location that is different from a source location and adestination location of the planned path, wherein obtaining the new pathfor the second mobile drive unit is based at least in part ondetermining that the obstacle location is different from the sourcelocation and the destination location.
 18. The non-transitorycomputer-readable storage medium of claim 14, wherein altering the taskexecution of the second mobile drive unit further comprises transmittingan indication that the new path is available, wherein transmitting theindication causes the second mobile drive unit to reserve space along atleast a portion of the new path.
 19. The non-transitorycomputer-readable storage medium of claim 14, wherein the operationsfurther comprise: generating a first metric associated with the plannedpath, wherein the first metric is determined based at least in part on afirst estimated completion time for the task if the task is executedutilizing the planned path; and generating a second metric associatedwith the new path, wherein the second metric is determined based atleast in part on a second estimated completion time for the task if thetask is executed utilizing the new path, wherein altering the taskexecution of the second mobile drive unit is based at least in part on acomparison of the first metric and the second metric.
 20. Thenon-transitory computer-readable storage medium of claim 19, wherein theoperations further comprise: determining an indicator value to beprovided to the second mobile drive unit based at least in part on acomparison of the first metric and the second metric, the indicatorvalue indicating that the task is infeasible and a reassignment of thetask is required, that a cheaper path is available with respect to thetask, or that execution of the task is required to be completedutilizing the new path.